1. Executive summary
Microsoft's Digital Crimes Unit, working with Health-ISAC, Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation and TRM Labs, has seized 50 websites operating the EvilTokens phishing service and disabled more than 150 additional domains tied to its infrastructure, under authorisation from the US District Court for the Eastern District of Virginia. London's Metropolitan Police Service arrested two men, aged 32 and 38, on 18 September on suspicion of making articles for use in fraud and money laundering; both are alleged EvilTokens operators, have been released on bail, and the investigation continues. EvilTokens was a device-code phishing kit, sold via Telegram at a $1,500 initiation fee plus $500 per month, that bypassed MFA and silently authenticated criminals as victims to Microsoft 365 applications; it compromised more than 12,000 email inboxes across over 10,000 organisations worldwide between its February 2026 launch and the takedown. Its distinguishing capability was an AI chatbot, drawing on multiple AI models, that analysed compromised inboxes to identify trusted relationships, payment authorisations and sensitive responsibilities, then recommended and drafted fraud messages impersonating trusted contacts. Attribution to the two arrested men rests on Microsoft and Metropolitan Police statements; the actor name "Eviltokens" has no MITRE ATT&CK profile and the attribution remains unconfirmed pending prosecution. The infrastructure is disrupted but the takedown does not remediate the 12,000-plus compromised inboxes, and Microsoft's own assessment is that the model will persist.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. The takedown is a law-enforcement and vendor action against criminal infrastructure; the obligations it touches (incident handling, reporting of any compromise found in a client's own tenant) are triggered by a client's own incident facts, not by this event. Organisations that find EvilTokens-related compromise during the retrospective review in §4 should assess their position under their existing incident classification and reporting processes.
3. Technical analysis & attack chain
EvilTokens was a phishing-as-a-service platform, available on Telegram for a $1,500 initiation fee and a recurring $500 monthly subscription, that combined device-code phishing with an AI chatbot applied across the criminal workflow. Microsoft describes it as its first action against an end-to-end AI-enabled cybercrime service, and as using AI "at every step of the attack chain". The confirmed sequence, as described by Microsoft and reporting on the takedown:
- Criminal buyers used pre-built phishing templates and landing pages, delivered through deceptive emails built on 44 different themes, ranging from invoices to file-sharing requests. The emails typically contained malicious URLs, PDFs or other file types.
- The phishing flow was a device-code phishing kit: the victim was induced to complete an authentication flow that let the criminal silently authenticate as the victim to the organisation's Microsoft 365 applications, bypassing MFA. The sources do not give the specific device-code flow steps or the exact endpoints abused, so we do not reconstruct them here.
- Once the inbox was compromised, the AI chatbot analysed its contents. It identified trusted relationships, payment authorisations and sensitive responsibilities, and other circumstances where fraud was most likely to succeed.
- The chatbot recommended fraud strategies and drafted messages impersonating trusted contacts, to trick victims or their contacts into taking action, including payment redirection. Microsoft's framing: the AI did not simply help attackers write more convincing messages, it decided who to target, who to impersonate, and how to extract as much money as possible.
- Criminals monetised the access through fraud against the compromised organisation and its contacts.
Scale and tempo: Microsoft observed 10 to 15 distinct campaigns launching every 24 hours since 15 March 2026. Compromises spanned more than 12,000 email inboxes across over 10,000 organisations worldwide, concentrated in the US, Canada, UK, Australia, India and France. Healthcare organisations were among those targeted, which is why Health-ISAC joined Microsoft's legal action as a co-plaintiff.
The takedown: Microsoft and Health-ISAC obtained authorisation from the US District Court for the Eastern District of Virginia, then worked with Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation and TRM Labs to seize 50 websites operating the service and disable more than 150 additional domains. Microsoft notified affected customers and helped them remediate compromised accounts. The Metropolitan Police Service executed warrants at two London locations on 18 September and arrested two men, aged 32 and 38, suspected administrators of the EvilTokens website; both are released on bail. Microsoft reported the matter to the Met in August 2026. Microsoft believes others may have supported the service in various capacities; the service's supporting infrastructure is disrupted but the criminal model it demonstrated is expected to persist.
Caveats on sourcing and attribution. The technical description of the kit's operation, the compromise figures and the campaign tempo all come from Microsoft's own statements and blog, relayed through The Register and Recorded Future News; they are single-sourced to Microsoft and not independently corroborated. Microsoft declined to name the AI platforms beyond OpenAI's role as a disruption partner, so the "multiple AI models" claim cannot be verified. The two arrested men are alleged operators; the case is at the arrest-and-bail stage and no prosecution outcome exists. "Eviltokens" has no MITRE ATT&CK profile, so we treat the attribution as unconfirmed.
4. Mitigation & containment
This is a takedown of criminal infrastructure, not a patch event. The actions below are the process and identity controls the incident actually implicates: retrospective review for compromise, payment-verification controls against the fraud the kit enabled, and hardening against device-code phishing.
P1, within 24 hours:
- Check whether Microsoft has notified your organisation of affected accounts. Microsoft notified affected customers and helped them remediate; if a notification has arrived and not been actioned, treat those accounts as compromised now. Revoke active sessions and tokens for any notified account, force credential reset, and re-enrol MFA where the device-code flow may have registered attacker-controlled authentication.
- Review sign-in logs for device-code flow activity against your Microsoft 365 tenant over the period February 2026 to the takedown date. Look for authentications consistent with device-code phishing: token issuance events where the user was not at the device that completed the flow, and impossible-travel or unfamiliar-IP patterns on Exchange/OAuth token use. The sources do not provide specific log event IDs, so build this review from your tenant's sign-in and audit logs rather than a published detection package.
- Suspend payment-change and redirection requests that arrived by email since February 2026 and have not been executed through a verified second channel. EvilTokens' core monetisation path was impersonating trusted contacts to redirect payments; any change to payment information, funds routing or unusual transaction approval in that window needs independent verification through a trusted second channel before it stands.
P2, within 72 hours:
- Block the takedown's residual risk: assume copycat kits exist. Disable or restrict the device-code flow for users who do not need it, and apply conditional access policies that constrain token issuance by location, device compliance and sign-in risk. The sources do not name the specific Microsoft 365 configuration controls, so align this with your existing conditional access baseline rather than a vendor-published hardening guide for this kit.
- Brief finance, payments and AP teams on the specific fraud pattern: an email from a known contact, referencing real relationships and real payment authorisations visible in a compromised inbox, requesting a payment change or an unusual approval. The AI's advantage was context from the inbox, so the counter-control is a callback to a number already on file, not a reply to the email.
- Review any third-party or outsourced email administration against this incident. If a managed service provider holds delegated access to your Microsoft 365 tenant, confirm with them that they have performed the same retrospective review.
P3, within 7 days:
- Run a targeted review of mailboxes with payment, treasury or supplier-management responsibilities for signs of inbox rule creation, forwarding changes or OAuth consent grants in the February-to-September window. The sources do not state that EvilTokens created such artefacts, so treat this as a standard compromise review, not a kit-specific hunt.
- Update fraud operations procedures to require second-channel verification for payment-detail changes, and record the EvilTokens pattern in your fraud typology library for staff training.
- If your organisation was among the compromised and the incident meets your internal classification thresholds, run it through your incident classification and reporting process; the takedown itself does not create a reporting obligation.
5. Indicators of compromise
No indicators of compromise available in the source material. The sources name no domains, IPs, hashes, file names or URLs from the seized infrastructure, and the 50 seized websites and 150-plus disabled domains are not itemised in the reporting.
Behaviours described in the sources are covered in §6.
6. Detection
The sources contain no atomic artefacts: no domains, hashes, file paths, registry keys, mutexes or command-line strings from the kit or its infrastructure. The 44 email themes are described only as "ranging from invoices to file sharing requests" and are not enumerated. A YARA rule cannot be authored from this material, and a Sigma rule would require log event specifics the sources do not give. We will not emit rules built from vendor headline phrases or the actor name, as those detect reporting about the threat, not the threat.
Insufficient indicators to author detection rules.
For monitoring, the behaviours to watch in your own tenant are those described in §3 and the P1 log review in §4: device-code flow authentications where the completing device or IP is inconsistent with the user's profile, and subsequent token use from unfamiliar locations.
7. Sources
- The Register, "UK Cops arrest 2 EvilTokens suspects, Microsoft seizes 50 phishing kit websites", https://www.theregister.com/security/2026/09/22/uk-cops-arrest-2-eviltokens-suspects-microsoft-seizes-50-phishing-kit-websites/5298317, 2026-09-22
- The Hacker News, "Microsoft Takes Down EvilTokens Device-Code Phishing Service Tied to 12,000 Inbox Compromises", https://thehackernews.com/2026/09/microsoft-takes-down-eviltokens-device.html, 2026-09
- Recorded Future News, "Two arrested in UK after Microsoft takedown of 'Eviltokens' AI-chatbot for cybercriminals", https://therecord.media/two-arrested-in-uk-after-microsoft-takedown-eviltokens, 2026-09-22
8. Adverse Trace position
The takedown removes the EvilTokens platform but not its effects: more than 12,000 compromised inboxes across over 10,000 organisations, with the US, Canada, UK, Australia, India and France most affected, and the fraud that followed those compromises is already in motion or already completed. For EMEA financial services the exposure is twofold: direct tenant compromise, which the P1 retrospective review addresses, and second-order fraud, where a client's suppliers, counterparties or customers were compromised and payment instructions impersonating the client are in circulation. The technical detail on the kit is single-sourced to Microsoft and we have flagged it as such; the attribution to the two arrested men is unconfirmed pending prosecution and the actor has no MITRE profile. We assess the operational lesson as Microsoft states it: assume that once an inbox is compromised, criminals understand its contents in minutes, not days, which makes second-channel verification of payment changes the control that actually breaks this fraud chain. We will monitor for the release of the seized domain lists and any Microsoft technical blog with tenant-level detection guidance, and will issue a follow-up advisory with IOCs and detection rules if that material is published.
Published via PulseTrace — Adverse Trace threat intelligence.