EvilTokens: 12,000 inboxes hacked without stealing a single password
Listen to the audio version
On September 22, 2026, Microsoft announced it had taken down EvilTokens, a turnkey phishing service used to compromise more than 12,000 inboxes across more than 10,000 organizations. France is among the hardest-hit countries, alongside the United States, Canada, the United Kingdom, Australia, and India. What makes this case unusual is that the victims never gave their password to a fake site: they signed in on the real one.
What happened
First seen in February 2026, EvilTokens was sold on Telegram as a subscription: a 1,500-dollar entry fee, then 500 dollars a month, for a complete, ready-to-use phishing infrastructure. Coinbase traced around 1.1 million dollars in revenue linked to the platform.
The takedown, authorized by a US federal court in Virginia, brought Microsoft and Health-ISAC (a threat-information-sharing organization for the healthcare sector) together with Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, the Shadowserver Foundation, and TRM Labs. Fifty websites used to run the service were seized, and more than 150 domain names tied to its infrastructure disabled. In the United Kingdom, London police had already arrested two men aged 32 and 38 on September 11.
A technique that goes through the real sign-in page
EvilTokens hijacked a perfectly legitimate Microsoft feature, device code sign-in. It exists for devices on which typing a password is awkward, like a smart TV or a meeting room screen: the device shows a short code, and the user goes, from their phone or computer, to Microsoft's official page to enter that code and sign in normally, two-factor authentication included. The device then receives access to the account.
The attackers requested a code from Microsoft themselves, then sent it to their target in a believable message, inviting them to enter it to view a document or approve an operation. The victim went to Microsoft's genuine address, saw a perfectly valid HTTPS padlock (see the article on the HTTPS padlock), the right domain name, their own two-factor authentication prompt (see the dedicated article), and approved everything without noticing anything wrong. Except that the "device" they were authorizing belonged to the attacker.
Even a passkey (see the article on passkeys) offers no protection here: it checks that the site is the real one, and it is. The problem isn't where the victim signs in, but what they agree to authorize.
Why changing the password isn't enough
A device code sign-in doesn't hand the attacker a password, but access tokens: small digital keys proving a sign-in has already been approved, some of which can stay usable for weeks or months. Microsoft stresses it explicitly: access could persist even after a password change, as long as the associated sessions and tokens weren't revoked as well. It's the same trap as in the Klue breach, where a token forgotten since 2022 had been enough to affect 200 companies.
An AI assistant to find the money
Once inside the inbox, EvilTokens offered its customers a conversational assistant, with ready-made prompts: find bank transfer discussions, locate supplier invoices, identify the people who handle payments in the organization, and work out whom to impersonate to be most convincing. The end goal wasn't the email itself, but the fraud that could follow: a fake change of bank details sent from a supplier's or colleague's real inbox, at the exact moment a payment was expected. A direct application of the techniques described in the article on social engineering, made much faster by automation.
What to take away
- Never enter a code received from someone else on a sign-in page: a device code only makes sense if you've just started the sign-in yourself on a TV, console, or screen right in front of you
- Verify any request to change bank details or any unusual payment through a trusted second channel, such as a call to an already-known number; that's Microsoft's own recommendation
- For organizations: turn off device code sign-in wherever it serves no purpose, and after a compromise, revoke all active sessions rather than just resetting the password
EvilTokens didn't break two-factor authentication. It got its victims to approve it themselves, for someone else, on the real page. A reminder that the trust signals we learn to check (the address, the padlock, the approval prompt) tell you where you are, never whom you're actually giving access to.