The EvilTokens panel came with a chatbot. Point it at a stolen mailbox and it would tell the fraudster who moved the money, which invoices were waiting to be paid and which colleague to impersonate so that the transfer went through. On 15 September 2026 a federal court in Virginia authorised Microsoft to seize the service's domains. On the 22nd, Microsoft announced the result: 50 websites seized and more than 150 supporting domains disabled, and two men aged 32 and 38 arrested in London by the Metropolitan Police as its suspected administrators.
EvilTokens had been trading since February, by Microsoft's dating, and in that time had put more than 12,000 Microsoft 365 inboxes in its customers' hands.
The figures are not what set it apart. The way in, device code phishing, has been documented since 2020: the attacker starts an Entra ID authorisation flow meant for devices without a keyboard, asks the victim to type the code into Microsoft's genuine sign-in page, and once the victim has entered a password and second factor it is the attacker's software that collects the tokens.
What was new came afterwards. Steven Masada, general manager of Microsoft's Digital Crimes Unit (DCU), summed it up in his statement: the AI was not simply helping attackers write more convincing messages; it helped them decide who to target, who to impersonate and how to exploit the relationship for the largest possible sum.
Much of the debate about AI and phishing has revolved around the lure: flawless emails and sign-in pages indistinguishable from the real one. EvilTokens suggests that AI really changes the economics of fraud at a later stage, once the attacker already has a mailbox open and needs to understand it before the access is cut off.
What the data says
Volume and price
According to Microsoft, EvilTokens launched in February 2026 and within months was linked to more than 12,000 compromised inboxes in over 10,000 organisations. A company spokesperson told CyberScoop that roughly a thousand criminals used the service and that Microsoft could tie at least 13 complaints filed with the FBI's IC3 to kit activity, representing about $1.7 million in reported losses. Microsoft considers that figure conservative: plenty of incidents are never reported, and not every victim can be traced to a particular campaign.
Access was sold over Telegram for a $1,500 set-up fee and $500 a month, with the bulk sender and the anti-bot redirector priced separately. Coinbase, which took part in the investigation, traced around $1.1 million in revenue across four Tron addresses attributed to the platform, made up of more than 1,000 deposits from over 700 distinct addresses. Coinbase dates that activity from October 2025 to June 2026, several months before the kit was advertised on Telegram, a gap none of the sources explains.
The victims were businesses, and a few customers did most of the damage
SpyCloud contributed the data it had recovered from the kit's own infrastructure to the lawsuit and published its analysis the same day: 8,708 unique accounts captured since 18 February, across 6,585 corporate email domains in 79 countries. Some 97.5% belonged to business domains; only 216 were free webmail accounts. The timing tracks the North American working day: an average weekday saw about seven times as many captures as a day at the weekend.
The most revealing part of that report is how concentrated the activity was. The ten most active EvilTokens customers account for 60% of the victims, and the top 25 for 85%. The twelve highest-volume customers drew, on average, 74% of their victims from a single country, which SpyCloud reads as campaigns aimed at particular kinds of company rather than opportunistic distribution. Microsoft puts the number of criminals who used the service at around a thousand, but in SpyCloud's data most of the harm comes from a couple of dozen of them.
What the AI did with the mailbox
Sekoia's analysis, cited by SpyCloud, found that the panel pulled up to 5,000 recent emails from the victim through Microsoft Graph, analysed the environment, picked out the fraud opportunities and drafted the impersonation email. It worked in more than twenty languages and flagged whether a captured account was a global administrator. Cloudflare's report adds an AI "coach" that briefed customers on US tax forms, business email compromise and the usual layout of invoices and accounting correspondence.
Microsoft Threat Intelligence's technical analysis supplies the timeline from inside the incidents. In some cases the attacker had registered a new device within ten minutes of the compromise, to obtain a Primary Refresh Token and secure persistence; in others they waited several hours before creating inbox rules or exfiltrating mail, so as not to trip immediate alerts. In one of the incidents analysed, the actor used the kit's AI features to sift the pool of captured accounts for financial, executive and administrative profiles, and saved the close reading for people who could authorise payments.
It ran on ordinary cloud infrastructure
Cloudflare reports that EvilTokens customers could paste their own Cloudflare API key into the panel, which used it to deploy a Worker carrying the capture page. Microsoft also saw Vercel, Cloudflare Workers and AWS Lambda used as redirection layers: phishing traffic blended into legitimate cloud traffic and got past domain blocklists. The takedown also ran into a legal limit: some domains were held by registrars in jurisdictions that do not cooperate, and for those Cloudflare placed interstitial warning pages in front of the phishing links rather than seizing them.
What has changed in a year?
The first change is that the technique is now sold as a product. SpyCloud describes device code phishing as a route into Microsoft 365 documented since at least 2020, and EvilTokens as the first commodity kit to offer it at scale, with rival platforms copying it within months. Back in April, Microsoft told The Register that since 15 March it had been seeing 10 to 15 new campaigns every 24 hours. For any defender, a technique moving from a few advanced groups to a thousand subscribers changes the odds of being on the receiving end.
The second change is the role of the AI. EvilTokens also used it to tailor the lure to the victim's role, across 44 prebuilt themes, but what sets it apart from earlier kits happens afterwards, inside the mailbox. TRM Labs, which followed the money, describes it as a compression of the time between compromise and monetisation. Trevor Hilligoss of SpyCloud was more direct: reading mailboxes in more than twenty languages to find the one conversation worth hijacking was the part of business email compromise that needed a human, and its yield depended on how good that person was. EvilTokens offered it to anyone for $500 a month.
The third is who sat in the coalition. Alongside Microsoft and Health-ISAC, which joined as co-plaintiff because hospitals were among the victims, stand Cloudflare, Railway, OpenAI, Coinbase, SpyCloud, Shadowserver and TRM Labs: cloud hosting platforms, an AI model provider, a cryptocurrency platform and threat intelligence firms. It is the fortieth court-authorised action by Microsoft's unit in nearly two decades and, according to Masada, the first against an end-to-end AI-enabled criminal service.
Why revoking the session is not enough: the EvilTokens lesson
What follows applies to other token-stealing kits as well, such as adversary-in-the-middle (AiTM) phishing. If an attacker can make sense of a mailbox in minutes, an incident playbook that sets aside hours to "assess the scope" is already late.
Microsoft's guidance describes a specific problem. In recent campaigns, standard session revocation invalidates refresh tokens but leaves already-issued access tokens alive for up to an hour, and the operators of these kits frequently exploit that window. That is why Microsoft recommends, unusually, disabling the compromised account for a time even at the cost of someone's working day. If there are signs the attacker registered a device, that device has to be disabled too: that is what stops the Primary Refresh Token from working, which revoking tokens alone does not achieve.
SpyCloud supplies the other half. Refresh tokens have a 90-day inactivity window and no fixed maximum age, so regular use extends access indefinitely. A password reset invalidates them in cloud-managed tenants, but hybrid and federated set-ups can fail to propagate the revocation, and whatever the attacker registered in the meantime survives the reset. An infrastructure takedown touches none of that: tokens already issued to EvilTokens customers may remain valid until each organisation revokes them.
At Hard2bit Cybersecurity the case prompted a review of an assumption found in several incident playbooks: that resetting the password and enforcing MFA ends an identity intrusion. With device code phishing it does not, and the check that was missing covers devices, authentication methods and inbox rules added during the access window.
Which controls still hold after EvilTokens?
Start with two answers that still appear in vendor questionnaires and no longer suffice on their own. "We have MFA enabled": the device code flow completes authentication and the second factor on Microsoft's genuine page, so the attacker receives tokens with MFA already satisfied. "We block known phishing domains": the lure is served from Workers, Vercel or Lambda on short-lived infrastructure; in a single April campaign Microsoft counted thousands of ephemeral polling nodes.
The controls that do hold act on the flow itself and on what happens next. The first is blocking the device code flow in Entra ID Conditional Access, with an exception only for the Teams device resource accounts that need it and the exclusion Microsoft documents for the Device Registration Service. It is the cheapest control on this list, and it is frequently found missing. The step-by-step configuration is in our guide on how to block device code phishing in Microsoft 365.
The second is phishing-resistant authentication with passkeys or FIDO2 security keys for accounts that can approve payments or administer the tenant, which Microsoft, SpyCloud and Cloudflare each recommend independently. The third is Continuous Access Evaluation (CAE), so that a change in risk ends the session without waiting for the token to expire.
On detection, Microsoft has published the alerts it raises for this chain, and they work as a checklist of what a SIEM should cover even without Defender: anomalous device code authentication, a token exchange following that authentication, device registration after a suspicious sign-in, an anomalous volume of Microsoft Graph requests after that sign-in, and inbox rule creation on its heels. The Graph and inbox-rule pair is the chatbot's footprint: to read 5,000 emails you have to request them, and the request is logged.
A SOC that correlates the sign-in's authentication protocol with the volume of Graph calls over the following hour sees the whole chain; one that looks only at the sign-in sees a legitimate user with MFA.
Beyond the technology sits the measure Masada singles out as the lesson for organisations, alongside strong identity protection: verify through a trusted second channel any request to change payment details, redirect funds or approve an unusual transaction. If the attacker has read the entire negotiation thread, the email they send will be consistent with everything before it, so consistency no longer proves anything.
After the takedown
The coalition's own members say as much. SpyCloud notes that other phishing-as-a-service platforms use the same technique, and Masada warns that the model EvilTokens demonstrated will outlive its infrastructure. Nobody publishes adoption figures for the controls that stop it, so on that point there is only field observation: in the Microsoft 365 tenants the Hard2bit team examines during an audit or an incident response, the device code flow is usually still enabled for every user, because nobody needed it and nobody switched it off. That is where Hard2bit's Microsoft 365 security service starts.
The operation leaves two questions open. One is how many of the 12,000 inboxes remain open to their buyers: Microsoft has notified affected customers, but revocation is up to each organisation. The other is what becomes of the service's customers: the coalition has shared intelligence on some of them with law enforcement, but no arrests have been reported. Even the date of the London arrests differs between sources: The Register and CyberScoop give 18 September; TRM Labs, a member of the coalition, and The Hacker News give 11 September.
This article is provided for informational and defensive purposes and reflects the information available on its publication date. The EvilTokens data comes from public disclosures by Microsoft, SpyCloud, Cloudflare, TRM Labs and the outlets cited; the victim, revenue and loss figures are those each organisation has published and may change as investigations continue, as may the attribution to the two men arrested, who are on bail and have not been convicted. It is not advice for a specific case: if you want to check how exposed your Microsoft 365 tenant is to device code phishing, [talk to the Hard2bit team](/en/contact/).
Frequently asked questions
What was EvilTokens and how long had it been running?
▾
A subscription phishing service advertised on Telegram from early 2026 (Microsoft dates it to February, Cloudflare to January) that sold, for a $1,500 set-up fee and $500 a month, a panel for stealing Microsoft 365 tokens through device code phishing. What set it apart was a chatbot that analysed the compromised mailbox and prepared the fraud: it identified who authorised payments, located outstanding invoices and drafted the impersonation email. Microsoft attributes its development to the actor it tracks as Storm-2992.
How many organisations were affected, and where do the figures come from?
▾
Microsoft links the service to more than 12,000 inboxes across over 10,000 organisations. SpyCloud, using the data it recovered from the kit's infrastructure, counts 8,708 accounts across 6,585 corporate domains in 79 countries; the two figures overlap and measure the same thing from two different vantage points, so they are not additive. Known losses are partial: Microsoft correlated 13 IC3 complaints worth about $1.7 million and cautions that this is a low estimate.
How is an infrastructure takedown different from remediation inside my tenant?
▾
They act on different things. The takedown reaches what belonged to the criminals: domains, Workers, the panel and the Telegram accounts. What the criminals obtained from each victim (refresh tokens, a registered device, an inbox rule) lives in the victim's tenant, and neither Microsoft nor the court has touched anything there. That is why a seizure can leave a buyer of the kit with working access to a mailbox for weeks, and why remediation has to be done by each organisation inside its own tenant.
Why does device code phishing work even when the company has MFA?
▾
Because the victim satisfies MFA and somebody else receives the token. To the Entra ID sign-in log, what happened is a legitimate sign-in with the correct password and second factor on a Microsoft page; the only thing out of the ordinary is the authentication protocol, which shows as device code. That is why the effective control is to block that flow or require phishing-resistant methods, and why adding another second factor to the same flow makes no difference.
What trace does the chatbot leave in Microsoft 365 logs?
▾
Three events in a particular order: a sign-in whose protocol is device code, a spike in Microsoft Graph requests over the following hour (the panel asked for up to 5,000 emails), and then a device registration or a new inbox rule. Each on its own is noise; the sequence is the chatbot. Microsoft has Defender alerts for every link, and anyone on another SIEM can rebuild the same sequence from the Entra ID sign-in logs and the Microsoft 365 audit log.
Should I block the device code flow in my Entra ID tenant?
▾
Yes, unless you have a documented reason not to. Microsoft recommends blocking the device code flow through a Conditional Access policy; if the organisation runs Teams devices or meeting rooms that depend on it, the exception should be scoped to their resource accounts and exclude the Device Registration Service. Before blocking it, check the sign-in logs for who has used the flow recently (Entra ID keeps 30 days with a P1 or P2 licence; export them to a SIEM to look further back): if the answer is nobody, the policy will not break anything.
What should I do if I suspect an account at my company was captured by EvilTokens?
▾
Treat it as a full identity intrusion, not a password phish. In practice: disable the account rather than only revoking sessions, remove the devices and authentication methods added during the suspicious window, delete inbox rules and authorised applications, and use the audit log to work out which emails were read and who was written to from the account. With that list, warn the people and suppliers the attacker may have corresponded with in the victim's name, because the fraud usually arrives in a later email that is already consistent with everything that was read.
Who took part in the EvilTokens operation, and what remains open?
▾
Microsoft and Health-ISAC as plaintiffs, authorised by the US District Court for the Eastern District of Virginia, together with Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, Shadowserver and TRM Labs; in London, the Metropolitan Police arrested two men who remain on bail. Each partner brought its own piece: Cloudflare disabled Workers and accounts, Coinbase and TRM Labs followed the money, SpyCloud supplied the victim data; Microsoft does not spell out what OpenAI and Railway did. What the operation does not reach are the service's subscribers: the coalition has shared intelligence on some of them with law enforcement, but no arrests have been reported.
