What happened
Microsoft says EvilTokens emerged in February 2026 as a phishing-as-a-service platform focused on device-code authentication abuse. Microsoft linked EvilTokens to more than 12,000 compromised inboxes across over 10,000 organisations worldwide. Observed activity spanned industries including financial services, healthcare, higher education, construction, real estate and wholesale distribution, with the highest concentrations in the United States, Canada, the United Kingdom, Australia, India and France.
The service initiated a legitimate device-code authentication flow and presented the resulting code to a target through a lure. After the user entered the code at Microsoft’s genuine sign-in page, the attacker’s backend received the authorised session without needing the user’s password. Microsoft observed the device-code script polling every three to five seconds during a 15-minute authentication window. Post-compromise activity included mailbox access, malicious inbox rules, device registration, Microsoft Graph reconnaissance and searches for financial conversations or trusted relationships.
The relevant system is the EvilTokens AI-style chatbot and its configurable AI Mode. The cited sources say EvilTokens drew on multiple AI models but do not identify model names or versions. Subscribers selected deployment method, capture mode, template, language, CAPTCHA and AI Mode in the EvilTokens panel. The platform generated target-specific lures, analysed compromised inboxes, mapped relationships and surfaced payment or impersonation opportunities after token theft. These were mechanically executed service functions selected or used by criminal operators, not evidence of independently inferred autonomy.
On September 11, 2026, UK police arrested two men on suspicion of offences connected with the alleged EvilTokens operation. On September 22, 2026, Microsoft disclosed the coordinated legal and technical disruption and published detailed defensive research. Microsoft seized 50 websites used to operate EvilTokens and disabled more than 150 additional domains tied to supporting infrastructure. Published detection names include Anomalous OAuth device code authentication activity, User account compromise via OAuth device code phishing and Suspicious inbox rule created after potential device code phishing sign-in. No complete public list of EvilTokens IP addresses or domains was included in the cited article text; Microsoft instead published behaviour-based detections and hunting queries. Attribution posture: Microsoft tracks the threat actor behind EvilTokens’ development and support as Storm-2992. The cited source did not publish the specific indicators described as Complete infrastructure indicator set.
Why this matters now
The disruption does not reduce the need to hunt. Device-code phishing uses Microsoft’s legitimate authentication page and can succeed without stealing a password, while subsequent tokens may support mailbox access, device registration, inbox-rule persistence and Microsoft Graph reconnaissance. Enterprises that treat successful MFA as proof of user intent can therefore miss the central control failure: the user authenticated an attacker-initiated session.
EvilTokens also shortens the interval between mailbox compromise and informed financial fraud. Its AI features were used to analyse messages, identify trusted relationships and prioritise people with payment or administrative authority. The practical response is not a generic AI ban. Security leaders need tightly scoped device-code exceptions, behaviour-based identity detection, rapid token containment and independent verification for changes to invoices, bank details or payment instructions.
The decision for security leaders
Assign the identity owner to enumerate every legitimate dependency on device-code flow and block it by default through Conditional Access. Exceptions should be limited to named resource accounts and devices, with an owner, business purpose, expiry date and monitoring requirement. Run the published detections across the longest available telemetry period and connect identity findings to mailbox, device-registration and Microsoft Graph activity.
Revise containment and fraud procedures for token-based compromise. Password reset alone may not remove active sessions or registered-device persistence. Suspected accounts need rapid disablement, token revocation and device review, while finance and procurement teams independently validate payment changes through a trusted channel. Treat suspicious inbox rules or internal phishing from a known mailbox as incident evidence, not merely email-filter failures.
Evidence of closure
- Conditional Access export showing device-code flow blocked or narrowly scoped.
- Hunt result covering the published device-code and token-exchange detections.
- Identity record confirming refresh-token revocation for every investigated account.
- Finance-control test confirming payment-change requests require an independent channel.
The Security.io assessment
The coordinated action meaningfully degrades the named service’s infrastructure, but it does not prove that every stolen token, compromised mailbox or customer-operated phishing deployment has been neutralised. Behaviour-based hunting remains necessary because the attack relied on legitimate identity endpoints and reputable hosting services. Successful authentication should be examined for user intent, device context and subsequent mailbox behaviour rather than accepted as conclusive proof of legitimacy.
This development warrants inclusion because the new disruption and technical disclosure quantify both campaign reach and the operational role of AI after account access. The decision change is specific: device-code authentication must become an explicitly governed exception, and mailbox compromise must be assumed to produce rapid organisational reconnaissance. The underlying risk is identity abuse and fraud acceleration, not an abstract claim that AI independently conducted attacks.
Questions for the morning meeting
- Where is device-code authentication genuinely required in the enterprise?
- Can identity teams disable suspected accounts before access tokens expire?
- Do finance controls verify payment changes outside a compromised mailbox?