EvilTokens: AI-Powered PhaaS Abusing Device Code Authentication to Compromise Over 12,000 Mailboxes

1. Basic Information

• Original Title: Unmasking EvilTokens: Getting to the root of device code phishing
• Publisher: Microsoft
• Publication Date: 2026-09-22
• Collection Date: 2026-09-23T08:14:06+09:00
• Original Source: Microsoft
• Severity: critical
• Severity Justification: Microsoft reports that over 12,000 email inboxes were compromised across more than 10,000 organizations worldwide since February 2026. Users are directed to legitimate Microsoft device login screens, and attackers trick victims into approving sessions initiated by the attackers to obtain tokens. After the compromise, these tokens are used for email theft, inbox rules, device registration, Microsoft Graph reconnaissance, and AI-driven business email compromise (BEC) targeting.
• Related Source: Microsoft DCU: Primary source on infrastructure disruption
• Related Source: SpyCloud: Joint investigation
• Related Source: BleepingComputer: Incident reporting
• Associated Malware: None
• Associated Threat Actor: Storm-2992
• Other Actors: EvilTokens subscribers/operators
• CVE: None
• Target Products and Services: Microsoft 365, Microsoft Entra ID, Microsoft Graph, OAuth 2.0 device authorization flow

2. Quick Summary

Developed and supported by Storm-2992, EvilTokens is a Phishing-as-a-Service (PhaaS) platform that offers 44 phishing themes and device-code phishing capabilities. It tricks users into approving attacker sessions on legitimate Microsoft pages to steal tokens and email data.

3. Attack Flow

From Device Code Phishing to Email Compromise

1. An EvilTokens user sends a high-urgency phishing email containing URLs, PDFs, or HTML attachments.
2. The landing script communicates with the Microsoft identity provider to generate a device code for the attacker's session.
3. The victim copies the code and goes to the legitimate microsoft.com/devicelogin page.
4. The victim performs legitimate authentication, including password and MFA, and approves access to the displayed application.
5. The attacker's polling process receives the token and accesses the victim's email and Microsoft Graph.
6. After compromise, attackers register new devices to obtain Primary Refresh Tokens (PRTs) for persistence, create inbox rules to conceal activity, and use AI to analyze inboxes and prepare BEC campaigns.

4. Attacker Roles and Execution Locations

• Storm-2992 developed and supports EvilTokens, while users purchase the service and execute the attacks.
• Authentication itself takes place on the legitimate Microsoft portal, but the initiating session and token recipient belong to the attacker.

5. Visibility for Victims and Administrators

Victim

• The final authentication screen is on the legitimate Microsoft domain. If the user is not already signed in, Microsoft requests their password and MFA; if an active session already exists, entering the code and confirming the request may be sufficient. This makes it difficult for the victim to realize they are approving an attacker's session.

Administrator

• Clues include abnormal OAuth device code authentication, token exchange immediately following authentication, high-volume Microsoft Graph calls, new device registrations, high-volume email retrieval, and suspicious inbox rules.

6. Success and Failure Conditions

Success Conditions

• The device code flow is enabled in the tenant.
• The victim inputs the attacker's code into the legitimate portal and approves the displayed access request.
• The victim completes the authorization before the device code expires, allowing the attacker’s backend to obtain access and refresh tokens.

Failure and Blocking Conditions

• Block the device code flow by default, allowing Conditional Access exceptions only for required Teams devices or similar use cases.
• Users verify the applications and requests displayed on the sign-in screen and abort suspicious code inputs.
• Temporarily disable compromised accounts, revoke refresh tokens and sessions, and disable or delete suspicious device registrations.

7. What Happens Upon Success

• Even without knowing the password, attackers can access email and Microsoft Graph using the token approved by the victim.
• Activities include email theft, concealment via inbox rules, new device registration, reconnaissance of organizational structure and permissions, internal phishing, and BEC.
• Microsoft has confirmed the compromise of over 12,000 inboxes.

8. Observable Logs

• email: Confirm EvilTokens phishing emails, URL/PDF/HTML attachments, post-compromise mass email reading, external forwarding, and suspicious inbox rules.
• proxy_swg_dns: Confirm multi-stage redirects via Vercel, Cloudflare Workers, AWS Lambda, etc., and transition to legitimate device login screens.
• endpoint_edr: Endpoint malware is not required. Use browser history, clipboard operations, and access to landing pages as supporting evidence.
• identity_idp: Confirm abnormal OAuth device code authentication, immediate token exchange, IP/device mismatches, new device registrations, and refresh token usage.
• saas_cloud: Confirm high-volume Microsoft Graph GET/POST requests, enumeration of email/organization information/permissions, and creation of inbox rules.
• network: Correlate communications to short-lived polling infrastructure or redirect destinations with post-authentication Microsoft Graph traffic.

9. Attack Success Determination

Confirmed via Public Information

• Information theft or session compromise confirmed: Microsoft confirmed the compromise of over 12,000 email inboxes across more than 10,000 organizations related to EvilTokens, observing email theft via tokens, inbox rules, new device registrations, and Graph reconnaissance.
• Subsequent compromise confirmed: Cases have been confirmed where compromised emails were analyzed using AI to select targets in finance, executive management, and administration, proceed with internal phishing, and prepare for BEC.

Organization-Specific Determination Criteria

• User action confirmed: Verify via browser history and authentication logs that the victim entered the attacker's code into the legitimate portal and approved the access request.
• Authentication and session compromise confirmed: Confirm that abnormal device code authentication and token exchange succeeded and were utilized from the attacker's IP address or device.
• Information theft or session compromise confirmed: Confirm token-based email and Graph access, data retrieval, inbox rules, and new device registrations.

10. Investigation Playbook

Trigger

• Start with abnormal OAuth device code authentication, immediate token exchange, high-volume Graph enumeration, inbox rules, and new device registrations.

Initial Verification

• Check the targeted user, authentication timestamp, device code flow, application, source IP, User-Agent, and redirect path.
• Preserve phishing emails, URLs, PDF/HTML attachments, and browser history.

Endpoint

• Check browser history, downloads, clipboard, and session cookie artifacts. Consider the possibility that no code execution occurred on the endpoint.

Authentication and Cloud

• Check OAuth grants, access tokens/refresh tokens, PRTs, new devices, Microsoft Graph, email audits, and inbox rules.

Subsequent Operations

• Track email theft, internal/external phishing emails, searches for payment information, enumeration of organizational structures, and BEC.

Containment

• Temporarily disable compromised accounts, and revoke refresh tokens and sessions, disable or delete suspicious devices, and remove unauthorized inbox rules.
• Block the device code flow by default and limit necessary usage via Conditional Access.

Decision Categories

• Evaluate separately: lure emails, code display, user approval, token acquisition, email/Graph access, persistence, and BEC.

11. Defense and Detection Ideas

Single Event

• Detect abnormal OAuth device code authentication, token exchange, new device registrations, and suspicious inbox rules with high priority.

Time-Series Correlation

• Correlate phishing emails, landing pages, device code authentication, token exchange, high-volume Graph enumeration, email retrieval, and inbox rules for the same user.

Threat Hunting Perspectives

• Cross-search for Microsoft Defender device code phishing-related detections, sudden surges in post-authentication Graph GET/POST requests, abnormal device registrations, and refresh token usage.

Log Gaps

• Authentication on the legitimate Microsoft portal alone cannot determine if the session was initiated by an attacker. Retain email, browser, authentication, Graph, and Exchange audit logs within the same session context.

Priority Mitigations

• Limit the device code flow to necessary resource accounts only, and enable Safe Links, anti-phishing protections, and risk-based Conditional Access.
• During a compromise, do not rely solely on standard session revocation; temporarily disable the account and delete suspicious devices.

12. Facts, Inference, and Hypothesis

Facts

• Microsoft reports that over 12,000 email inboxes were compromised across more than 10,000 organizations since February 2026.
• EvilTokens provided 44 themes, AI-driven generation of lure messages and inbox analysis, automatic token renewal, email scanning, and Microsoft Graph reconnaissance.
• In device code phishing, victims authenticate on the legitimate Microsoft portal and approve the attacker's session, leading to account compromise without handing over the password itself.
• Microsoft and its partners seized 50 websites and disabled more than 150 additional domains tied to the supporting infrastructure.

Inference

• Because authentication completes on legitimate Microsoft domains, monitoring only credential input destinations is insufficient. It is necessary to correlate the authentication initiator with post-approval token usage.

Hypothesis

• Even after infrastructure disruption, users may migrate to other PhaaS platforms and continue using the same device code technique.

13. MITRE ATT&CK Mapping

• T1566.002 Spearphishing Link (Confidence: High) — Direct URLs and links delivered through lure content redirect victims to the device-code flow.
• T1566.001 Spearphishing Attachment (Confidence: High) — PDF and HTML attachments were also used to deliver the phishing sequence.
• T1528 Steal Application Access Token (Confidence: high) — Attackers acquire OAuth tokens issued through victim approval.
• T1114.002 Remote Email Collection (Confidence: high) — Emails are retrieved from compromised inboxes.

14. Uncertainties and Additional Investigation

• The number of victims in Japanese organizations has not been made public.
• Remaining infrastructure after disruption, user migration destinations, and the number of undetected inboxes are unknown.

15. Impact on SOCs and Organizations

Even when using legitimate Microsoft screens and MFA, attackers can abuse device code authentication to trick users into approving an attacker-initiated session. Block the flow by default, make exceptions only for required devices and resource accounts, and correlate lure emails, device code authentication, token exchanges, Graph enumerations, and email operations within the same session.

16. Summary by Target Audience

• For SOCs: Track device code authentication, token exchanges, high-volume Graph enumerations, email retrievals, new devices, and inbox rules in chronological order for the same user.
• For Administrators: Block the device code flow by default and restrict necessary use cases via Conditional Access. During a compromise, temporarily disable accounts, revoke refresh tokens and sessions, and disable or delete suspicious device registrations.
• For Users: Do not enter device codes you did not initiate, and verify the displayed applications and request details even on legitimate Microsoft screens.