What happened
On September 22, 2026, Microsoft disclosed a court-authorised disruption that followed arrests of two men on September 11, 2026. Microsoft said the action seized 50 websites used to operate EvilTokens and disabled more than 150 additional domains tied to supporting infrastructure. Microsoft linked EvilTokens to more than 12,000 compromised inboxes across more than 10,000 organisations since its February 2026 launch. SpyCloud independently counted at least 8,708 accounts across 6,585 corporate domains in 79 countries, and said 97.5% of observed accounts belonged to enterprise domains.
EvilTokens abused Microsoft’s legitimate OAuth device-code flow: the attacker initiated the flow, the victim entered a code at Microsoft’s real device-login page, and the attacker received access and refresh tokens after the user completed authentication. Microsoft observed some actors registering new devices within 10 minutes of compromise to obtain a Primary Refresh Token for longer-term persistence. The platform also supported inbox-rule creation, email exfiltration and Microsoft Graph reconnaissance.
Agent or framework: EvilTokens’ AI-enabled mailbox-analysis assistant and phishing platform were the named system. Underlying model: The cited sources did not identify the underlying model or version. Operator configuration: Subscribers selected deployment methods, templates, CAPTCHA, AI Mode and captured-text options. Mechanical action: The platform queried Microsoft Graph, analysed compromised mailbox content, identified high-value targets and generated tailored fraud messages. Attribution posture: Microsoft tracks the developer and support actor behind EvilTokens as Storm-2992; the cited sources do not attribute every affiliate campaign to that actor.
Why this matters now
The disruption removes meaningful infrastructure and creates an unusually strong moment for retrospective hunting, but it does not prove that stolen sessions, registered devices, inbox rules or affiliate-controlled infrastructure have disappeared. Organisations must treat notified or suspicious accounts as identity incidents, not as phishing messages that ended when the original lure was deleted.
EvilTokens industrialised a legitimate OAuth flow that can satisfy MFA while transferring usable tokens to an attacker. It then combined mailbox access, organisational reconnaissance and fraud-message preparation. That sequence compresses the time between initial identity compromise and credible business email compromise, increasing pressure on identity, messaging, finance and incident-response teams to operate as one workflow.
Microsoft’s observations also challenge password-centred containment. Existing access tokens can remain usable briefly after standard session revocation, and attackers may register devices or create inbox rules. Closure therefore requires review of sessions, devices, OAuth activity, Microsoft Graph use, mailbox rules and financial communications.
The decision for security leaders
Use the disruption as a hunting trigger, not a declaration that exposure has ended. Identity engineering should define the legitimate device-code population, while the SOC searches for authentication, token, device and mailbox events that fall outside it.
Contain confirmed accounts in the correct order. Temporarily disable the identity to close the active-access window, revoke sessions and refresh tokens, remove registered devices and inbox persistence, review delegated access, and only then restore credentials and business access.
Treat financial process controls as part of cyber containment. Because the platform analysed trusted relationships and payment conversations, treasury and accounts-payable teams should verify changes through pre-established contact channels rather than relying on the compromised mailbox.
Evidence of closure
- Conditional Access export shows device-code flow blocked or limited to approved resource accounts.
- Hunt results disposition every anomalous device-code sign-in, token exchange and device registration.
- Compromised-account records show sessions revoked and unauthorised devices, rules and grants removed.
- Finance control evidence confirms independent verification of payment changes linked to affected mailboxes.
The Security.io assessment
The disruption is material because it combines court action, infrastructure seizure, victim notification and arrests with technical telemetry describing enterprise compromise at scale. It does not eliminate device-code phishing as a method or establish that every captured tenant has completed remediation.
The cited sources did not publish a complete enterprise-ready list of every seized or disabled EvilTokens domain. Domain matching alone is therefore insufficient for closure; behavioural evidence around device-code sign-ins, token exchange, device registration, Microsoft Graph activity and mailbox manipulation is more durable.
The AI element is operationally relevant but should not be overstated. The evidence supports automated analysis of mailbox content, target prioritisation and message preparation. It does not identify a specific underlying model version or establish that the system operated without subscriber configuration and affiliate direction.
Questions for the morning meeting
- Is device-code authentication disabled except for documented business requirements and tightly scoped resource accounts?
- Can identity teams identify device registrations, token exchanges and inbox-rule creation following anomalous device-code authentication?
- Are finance teams independently verifying payment-detail changes and unusual transfer requests through a trusted second channel?
- Who owns containment when a stolen session remains valid after ordinary password or refresh-token actions?