Much has been written about how the days of phishing emails laden with broken grammar and crude design are numbered, largely thanks to AI. Meanwhile, EvilTokens offers a somewhat different example of how far the phishing craft has moved.
EvilTokens is a phishing-as-a-service (PhaaS) kit built to compromise Microsoft 365 accounts by abusing the OAuth 2.0 device authorization grant flow. As attacks that use the kit rely on device code phishing, they sidestep the need for convincing replicas of genuine login pages where the victims would hand over their passwords. Instead, attackers get the victim to complete a legitimate authentication process – including two-factor authentication (2FA) – on a real Microsoft login page.
The toolkit has been advertised via Telegram channels and spotted in active attacks since at least February 2026. As documented by Sekoia and others, the kit appears to have been quickly adopted by cybercriminals and deployed in a number of account takeover and business email compromise (BEC) attacks, including for a campaign targeting more than 340 organizations in several countries in March 2026. Microsoft itself has also described an AI-enabled campaign that used dynamic device-code generation and bespoke lures to increase the success rate of EvilTokens attacks.
The inner workings of EvilTokens
Here’s a brief overview of how attacks leveraging EvilTokens unfold:
- The attack itself is preceded by ‘reconnaissance’ where the ne’er-do-wells first verify that the target account is active. Microsoft has seen this reconnaissance run 10 to 15 days ahead of the actual phishing attempt.
- The victim receives an email or message that’s often dressed up as an invoice, shared document, calendar invite, or SharePoint access request. The lure involves a decoy page impersonating a trusted brand or service, along with simple wording such as “Verify to view” or “Signature required.”
- When the victim clicks through, the page requests a device code from Microsoft. The code is valid only for 15 minutes, hence time and timing are of the essence here. The page shows the victim the code along and points them to Microsoft’s genuine microsoft.com/devicelogin login portal. The catch is that the code belongs to the attacker’s session, hence the victim unknowingly authorizes the attacker’s device, not their own.
- Seeing a valid sign-in, Microsoft issues access and refresh tokens to the session opened by the attacker. Once inside, the criminals can access corporate email, files, Teams, SharePoint, OneDrive, and other Microsoft 365 resources and exfiltrate data or prepare BEC attacks, which is why finance, HR, logistics, and sales accounts draw much of the attackers’ interest.
What makes EvilTokens dangerous
The OAuth device code flow was designed for devices that may be awkward to sign into directly, such as smart TVs or printers. The device displays a short code that the user enters on a Microsoft page on another device, often a smartphone, and completes authentication there. Microsoft then issues access tokens to the device that requested access.
That separation is useful, but it leaves room for abuse. Attackers can generate the code and dupe the victim into entering it – all while Microsoft only sees a valid authentication flow. The company does warn users at the moment of sign-in via on-screen text telling them not to enter codes from sources that they don’t trust. However, a convincing decoy is sometimes enough to get the victim to read past any warnings.
Speaking of which, EvilTokens strips out many of the red flags that people have been taught to notice over the years, including misspelled domain names and fake login pages. The login page is real and, from the victim’s point of view, the entire authentication process can appear to work as expected.
The attack also ‘muddies the waters’ when it comes to safeguards provided by 2FA. While the second authentication layer has never been more important, it falls short when the victim approves the wrong session. In these attacks, attackers don’t subvert 2FA through any technical wizardry – rather, they simply dupe the victim into completing 2FA for them.
How to reduce the risk
Phishing protection tips clearly can’t stop at “check the link,” let alone “look for typos.” Those habits still help, of course, but they don’t hold up against modern attacks, especially those that abuse real authentication flows.
Here are a few tips for staying safe from EvilTokens:
- Think of any unexpected request for an authentication code as suspect. No document, invoice, email, or another platform should ask for a device code without a clear reason. If the request arrives out of nowhere, flag it to your employer’s IT or security team.
- 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 actually started the action. A real Microsoft page doesn’t automatically make a request safe.
- Organizations should restrict device code flow outright where it’s not needed. Microsoft recommends applying Conditional Access policies to block device code flow wherever it isn’t necessary and scope it to specific users, devices, locations, or operating systems.
- Watch for unusual device-code authentication, unfamiliar devices, risky sign-ins, suspicious token use, and new inbox rules – any of these can point to trouble.
- Security awareness training needs to catch up with the latest tricks up attackers’ sleeves. Employees should understand that modern phishing doesn’t always involve typing a password into a fake page. Sometimes the attacker could ask them to enter a real code on a real page – but for the wrong device.
- Employees who receive an unexpected device-code request should notify their company’s IT or security teams, who may need to review sign-in logs, revoke sessions, invalidate refresh tokens, remove malicious inbox rules, and temporarily disable the compromised account.
EvilTokens is a reminder that attackers don’t always need to break the front door or steal the key to it. Sometimes they only need to talk someone into opening it.






