EvilTokens: a phishing attack that doesn't steal your password

Much has been written about how the days of phishing emails full of broken grammar and crude design are numbered, largely thanks to AI. EvilTokens is a different sort of example of how far the craft has moved — and it is a considerably less reassuring one.

EvilTokens is a phishing-as-a-service kit built to compromise Microsoft 365 accounts by abusing the OAuth 2.0 device authorization grant flow. Because attacks using it rely on device code phishing, they skip the usual requirement for a convincing replica of a login page. There is no fake page and no password to hand over. Instead the victim is walked through a genuine authentication process, two-factor authentication included, on a real Microsoft login page.

The toolkit has been advertised through Telegram channels and has been seen in active attacks since at least February 2026. It was adopted quickly, and has been used in account takeover and business email compromise campaigns — among them one in March 2026 that targeted more than 340 organisations across several countries. Campaigns have also been observed using dynamic device-code generation and tailored lures to push the success rate higher.

How an EvilTokens attack unfolds

1. Reconnaissance comes first. The attackers confirm that the target account is active. In observed campaigns this has run ten to fifteen days ahead of the phishing attempt itself.
2. The victim receives an email or a message dressed up as an invoice, a shared document, a calendar invitation or a request for access to a file. A decoy page impersonates a familiar brand, and the wording is deliberately plain: “Verify to view”, “Signature required”.
3. Clicking through, the page requests a device code from Microsoft. The code is valid for fifteen minutes only, which is why the timing is tight. The page displays the code and sends the victim to Microsoft's real device login portal — where they enter it.
4. The catch is whose session the code belongs to. It is the attacker's, so the victim has authorised the attacker's device rather than their own, without knowing that is what they were doing.
5. Microsoft, seeing a valid sign-in, issues access and refresh tokens to the session the attacker opened. From there the attackers can reach corporate email, files, Teams, SharePoint, OneDrive and the rest of Microsoft 365 — to exfiltrate data or to set up a business email compromise. It is why finance, HR, logistics and sales accounts attract most of the interest.

What makes it dangerous

The device code flow exists for devices that are awkward to sign into directly — a smart television, a printer. The device shows a short code, the user enters it on a Microsoft page from something more convenient, usually a phone, and Microsoft then issues access tokens to the device that asked for them. That separation is useful, and it is also the room the abuse lives in: the attacker generates the code and talks the victim into entering it, and all Microsoft ever sees is a valid authentication flow.

Microsoft does warn users at the point of sign-in, with on-screen text telling them not to enter codes from sources they do not trust. A convincing decoy is sometimes enough to get somebody to read past a warning.

EvilTokens also removes most of the red flags people have been taught to look for. There are no misspelled domains and no fake login page. The page is real, and from the victim's side the whole process behaves exactly as it should.

It muddies the reassurance of two-factor authentication as well. The second factor has never mattered more, and it does nothing at all when the victim approves the wrong session. Nothing technical is being subverted here. The victim is simply being talked into completing 2FA on the attacker's behalf.

How to reduce the risk

Phishing advice cannot stop at “check the link”, and it certainly cannot stop at “look for typos”. Those habits still help. They do not hold up against an attack that abuses a real authentication flow, and this is not the only one that does.

• Treat any unexpected request for an authentication code as suspect. No document, invoice, message or platform should ask for a device code without a clear reason. If it arrives out of nowhere, flag it to your employer's IT or security team rather than working it out yourself.
• Context matters more than the page. Before approving any sign-in request, check which app is asking for access, which account is involved, and whether you started the action at all. A real Microsoft page does not make a request safe.
• Organisations should restrict the device code flow outright wherever it is not needed, scoping it to specific users, devices, locations or operating systems through Conditional Access policies.
• Watch for unusual device-code authentication, unfamiliar devices, risky sign-ins, suspicious token use and new inbox rules. Any one of those can be the first sign of trouble.
• Security awareness training has to catch up. Employees need to understand that modern phishing does not always involve typing a password into a fake page. Sometimes it asks them to enter a real code on a real page — for the wrong device.
• Anyone who receives an unexpected device-code request should tell their IT or security team promptly. The response is time-sensitive: reviewing sign-in logs, revoking sessions, invalidating refresh tokens, removing malicious inbox rules and temporarily disabling the account.

EvilTokens is a reminder that attackers do not always need to break the front door, or steal the key to it. Sometimes all they need is to talk somebody into opening it.