The trap: the page is real, but the request is not
Classic phishing imitates a sign-in page to collect a password. EvilTokens exploits a subtler confusion: a victim may reach the real Microsoft website, enter their password, and complete MFA normally. They still authorize the session prepared by the attacker.
The kit, described by BGD e-GOV CIRT in July 2026 and analyzed by Microsoft, turns OAuth device-code authentication into a phishing service. The feature is designed for TVs, command-line tools, and devices that cannot offer a full sign-in interface. It asks a user to enter a short code on another device.
The context is the weakness. The attacker can request the code, then show it to the victim through a fake document preview, invoice, or urgent request. The Microsoft domain is genuine, but the authorization is pointed at the wrong session.
How EvilTokens redirects the flow
The scenario commonly has several steps:
- A credible message asks the person to open a document, invoice, or signing request.
- An intermediate page asks for an email address and dynamically prepares a device code.
- The page redirects to the real Microsoft address and asks the user to enter the code.
- The victim completes sign-in and MFA, believing they are opening their own session.
- The attacker’s backend receives access tokens for the session it initiated.
Recent kits generate the code when the victim clicks, so a static code does not expire before use. Some also manipulate the clipboard or encrypt the page until it is rendered in the browser. These details complicate detection, but the key rule stays simple: a device code must match an action the user deliberately started.
Why MFA is not enough here
MFA verifies the person’s identity. It does not always verify who started the request or which application context will receive the token. In this scenario, the attacker does not break MFA; they persuade the victim to approve a request the attacker controls.
An authentic page is therefore not sufficient evidence. Check the application, the expected action, and where the request came from. An unexpected invitation to enter a code at microsoft.com/devicelogin, or to approve a sign-in, should be cancelled and reported.
Practical measures for an SMB
For administrators
- Block device-code authentication in Microsoft Entra ID when no business device or tool requires it, and document necessary exceptions.
- Prefer phishing-resistant methods such as passkeys or FIDO2 security keys, and disable legacy authentication protocols.
- Enable the anti-phishing and safe-link protections available in your security suite.
- Monitor device-code sign-ins, new device registrations, newly added mailbox rules, and unusual Microsoft Graph activity.
- Rehearse revocation: sessions, tokens, newly registered devices, mailbox rules, and related secrets.
For users
- Never enter a code received in a message or displayed by an unexpected page.
- Reject any MFA prompt you did not initiate, even when the notification looks familiar.
- Open Microsoft 365 from a known bookmark instead of an urgent link.
- Tell IT as soon as something feels wrong; do not wait to find out whether the sign-in succeeded.
Respond quickly, without overstating the guarantees
After a suspicious approval, sequence matters: preserve the context, alert the administrator, revoke sessions and tokens, check mailbox rules and added devices, then assess what data may have been accessed. Changing one password may be insufficient if a session or token remains usable.
Secret management supports this response but does not replace it. Unique passwords per service prevent one compromised secret from becoming a wider incident. The Soclyde guide to local-first password managers explains how to keep an encrypted vault under the organization’s control and prepare its backups.
Soclyde does not protect the Microsoft 365 tenant, block OAuth flows, or replace MFA and endpoint detection. Its role is narrower: generate unique secrets, reduce centralized copies, and make rotation practical. Against EvilTokens, effective defense combines identity controls, human caution, logging, and the ability to revoke access quickly.
The rule worth sharing is simple: a Microsoft page can be genuine while the request it carries is fraudulent.
