EvilTokens PhaaS Disrupted After 12,000 Microsoft Accounts Breached

Executive Summary

In a coordinated international cybercrime takedown, Microsoft's Digital Crimes Unit (DCU), in collaboration with global law enforcement and industry cybersecurity partners, disrupted EvilTokens, a sophisticated Phishing-as-a-Service (PhaaS) platform. Operating since February 2026 under the operator moniker Storm-2992, the cybercrime operation facilitated the compromise of more than 12,000 Microsoft customer email inboxes across 10,000 commercial and public-sector organizations globally.

EvilTokens represented a dangerous evolution in identity-based attacks. The platform paired OAuth 2.0 Device Authorization Flow (device-code) phishing with an integrated generative artificial intelligence engine. By tricking enterprise users into authenticating malicious client applications on legitimate Microsoft authentication portals, adversaries bypassed traditional multi-factor authentication (MFA) controls. Post-compromise, EvilTokens utilized automated LLM agents to harvest financial communications, parse invoice pipelines, and execute highly targeted business email compromise (BEC) fraud.

Technical Vulnerability Analysis & Attack Chain

Unlike traditional Adversary-in-the-Middle (AiTM) reverse proxies that relay login pages to steal session cookies, EvilTokens subverted standard enterprise identity protocols by abusing legitimate cloud device authorization mechanisms.

1. OAuth 2.0 Device Authorization Abuse (RFC 8628)

Storm-2992 weaponized the OAuth 2.0 Device Authorization Grant (RFC 8628), a protocol originally engineered for input-constrained devices (such as smart televisions, gaming consoles, or command-line developer tools) that lack integrated web browsers. The attack sequence unfolds through distinct protocol stages:

• The attacker's automated infrastructure issues a backend POST request to the Microsoft Entra ID device code endpoint (/common/oauth2/v2.0/devicecode), specifying an OAuth client ID (frequently spoofing well-known tools like the Azure CLI 04b07795-8ddb-461a-bbee-02f9e1bf7b46 or native Microsoft Office suites).
• Entra ID returns a device_code, a user-facing user_code (e.g., B7KQ-8XLM), and the verification URI (https://microsoft.com/devicelogin).
• The attacker dispatches targeted lures (disguised as electronic document signing requests, urgent Microsoft Teams notifications, or shared OneDrive assets) instructing the victim to navigate to the official Microsoft portal and enter the supplied code.

2. AiTM Token Interception & MFA Neutralization

Because the victim visits the legitimate, verified microsoft.com domain on their own corporate-managed workstation, the authentication process does not trigger standard web reputation defenses or domain typosquatting alerts:

• The victim enters the user code and signs in using their corporate credentials.
• If Conditional Access prompts for Multi-Factor Authentication (Authenticator push notification, FIDO2 hardware token, or biometric Windows Hello), the victim satisfies the challenge natively on their trusted endpoint.
• Once verified, Entra ID grants the requested application consent and mints token responses to the waiting EvilTokens server polling in the background.
• EvilTokens captures the resulting Refresh Token and Access Token. Crucially, the adversary acquires authenticated session authority without ever observing, capturing, or knowing the victim's cleartext password.

3. Session Persistence Across Password Resets

Because authentication authority is anchored to the captured Refresh Token rather than the victim's password hash, standard password resets often fail to evict the adversary. The long-lived Refresh Token allows Storm-2992 affiliates to continuously request fresh Access Tokens scoped to Microsoft Graph API and Outlook Web Access (OWA), maintaining uninterrupted operational persistence unless tenant administrators explicitly issue a cryptographic token invalidation command.

4. Generative AI-Automated BEC Reconnaissance

EvilTokens distinguished itself from legacy PhaaS competitors through deep, turnkey generative AI integration:

• Upon capturing valid Graph API tokens, the platform automatically connected an integrated LLM backend directly into the compromised mailbox.
• The AI parsed months of email threads, extracting sensitive financial context, identifying vendor billing workflows, locating pending capital expenditures, and profiling internal C-suite communication cadences.
• The chatbot drafted context-aware, linguistically flawless wire fraud and account redirect requests, eliminating the spelling, formatting, and stylistic telltales historically used by security awareness training to spot spearphishing.

MITRE ATT&CK Tactics, Techniques & Procedures (TTPs)

Threat Actor Profile & Campaign Attribution

• Operator Tracking (Storm-2992): Microsoft Threat Intelligence tracks the developers and central operators of EvilTokens under the cluster designation Storm-2992. The group operated as a commercial PhaaS vendor, marketing subscriptions across dark web forums and private Telegram channels.
• Commercialization Model: Affiliates paid an initial onboarding fee of $1,500 followed by a $500 monthly recurring subscription. This tier provided automated infrastructure deployment, turnkey device-code proxy endpoints, and access to the AI BEC intelligence chatbot.
• Targeting Scope: Victims spanned more than 10,000 distinct tenant organizations across North America, Europe, and the Asia-Pacific region, with heaviest targeting observed in financial services, commercial real estate, healthcare, logistics, and higher education.
• Law Enforcement Enforcement: Following a federal seizure warrant issued by the U.S. District Court for the Eastern District of Virginia, Microsoft DCU and partners disabled over 175 malicious domains and seized 50 core command-and-control servers. Concurrently, the UK Metropolitan Police Cyber Crime Unit arrested two primary platform operators (aged 32 and 38) in the Greater London area on September 11, 2026.

Detection & SOC Mitigation Playbook

1. Identity & Conditional Access Controls

• Restrict OAuth 2.0 Device Code Flow:
  • In Microsoft Entra ID, navigate to Protection -> Conditional Access and deploy a strict policy blocking the Device Code grant flow for standard knowledge workers.
  • Limit Device Code authentication strictly to verified service accounts or headless operational devices located within dedicated corporate IP subnets.
• Enforce Phishing-Resistant MFA & Managed Devices:
  • Enforce FIDO2 security keys, Windows Hello for Business, or certificate-based authentication (CBA) bound to device health compliance via Microsoft Intune.

2. Token Invalidation & Session Hunting

• Immediate Session Revocation:
  • When a user reports entering an unexpected device code or is flagged by risk telemetry, reset credentials and immediately invalidate all issued tokens via PowerShell:

Revoke-AzureADUserAllRefreshToken -ObjectId <User-Object-ID>

• Audit Enterprise Application Consents:
  • Review Entra ID -> Enterprise Applications for unauthorized multi-tenant applications or unexpected OAuth permissions granted with Mail.Read, Mail.ReadWrite, or Mail.Send scopes.

3. Endpoint Detection & Hunting Query

Sigma Rule: Suspicious OAuth Device Code Flow Sign-In Activity in Entra ID

title: Suspicious Microsoft Entra ID Device Code Authentication
status: experimental
description: Detects user sign-ins utilizing OAuth 2.0 Device Code Flow originating from anomalous client apps or external locations.
logsource:
  service: azure
  product: entra_id
detection:
  selection:
    AuthenticationProtocol: 'deviceCode'
    AppDisplayName:
      - 'Microsoft Office'
      - 'Microsoft Command Line Utilities'
      - 'Azure CLI'
  filter_trusted:
    NetworkLocationDetails.networkType: 'trustedNamedLocation'
  condition: selection and not filter_trusted
level: high
tags:
  - attack.initial_access
  - attack.t1566.002
  - attack.credential_access
  - attack.t1539

Microsoft Sentinel / Defender (KQL) Hunting Query: Device Code Flow Exploitation & Token Abuse

// Identify anomalous Device Code Flow sign-ins followed by Graph API mailbox reads or forwarding rules
let DeviceSignins = SigninLogs
| where TimeGenerated > ago(7d)
| where AuthenticationProtocol =~ "deviceCode"
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, ClientAppUsed, UserAgent;
let MailAudit = OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation in~ ("New-InboxRule", "Set-InboxRule", "MailItemsAccessed")
| project TimeGenerated, UserId, Operation, ClientIP, OfficeWorkload;
DeviceSignins
| join kind=inner (MailAudit) on $left.UserPrincipalName == $right.UserId
| project SigninTime = TimeGenerated, MailAuditTime = TimeGenerated1, UserPrincipalName, IPAddress, Location, AppDisplayName, Operation
| sort by SigninTime desc