EvilTokens Just Compromised 340 Microsoft 365 Tenants in Five Weeks Without Asking for a Single Password—The Victims Finished MFA on the Real Microsoft Site

What Happened

On May 19, 2026, The Hacker News published the post mortem on EvilTokens, a phishing as a service platform that launched in February 2026 and compromised over 340 Microsoft 365 tenants across five countries within its first five weeks of operation. The platform does not need to clone a Microsoft sign in page. It does not need a reverse proxy. It does not need any of the infrastructure that has defined enterprise phishing for the last decade.

EvilTokens needs one thing: the victim to enter a short code on the real Microsoft sign in page and click Accept on a real OAuth consent prompt. Everything else is mechanics.

The Device Code Flow, Briefly

Microsoft's OAuth implementation includes a flow called "device code grant" that was originally designed for devices without a web browser—smart TVs, IoT controllers, command line tools, voice assistants. The shape of the flow is:

• The device requests a code from Microsoft.
• The device displays the code to the user and tells them to visit microsoft.com/devicelogin on a separate device.
• The user visits the page on their phone or laptop, enters the code, and authenticates with their normal Microsoft credentials including MFA.
• Microsoft asks the user to approve the requested scopes for the device.
• The user clicks Accept.
• Microsoft hands the device a refresh token that lets it call the requested APIs on the user's behalf for an extended period.

This is a legitimate flow. It is the same flow you use when you sign your Apple TV into your Microsoft account, or when you set up a meeting room display. The flow assumes the human who enters the code is the same human who owns the device requesting it.

EvilTokens breaks that assumption. The "device" that requests the code is not the user's. It is the attacker's. The user gets a code in a phishing email and enters it because the entire interaction looks legitimate—they are on the real Microsoft site, finishing real MFA, approving real scopes. The token Microsoft hands out at the end goes to the attacker.

Why MFA Cannot Stop It

Most defenders treat MFA as a backstop. If the password gets phished, MFA catches it. If the attacker is in the wrong country, conditional access flags the session. The whole secondary authentication layer is supposed to prevent unauthorized access even when the primary credentials have been compromised.

EvilTokens does not bypass MFA. It uses MFA against the defender. The victim authenticates on the legitimate Microsoft identity provider, completes the MFA challenge on the legitimate domain, and clicks Accept on the real OAuth consent screen. From Microsoft's perspective, this is the canonical happy path. There is no anomalous login to flag, no suspicious geography to alert on, no unusual session pattern to model. The user did exactly what they were supposed to do. The system worked as designed.

The article describes the resulting token in plain terms: the user "had actually handed the operator a valid refresh token scoped to their mailbox, drive, calendar, and contacts." Once the attacker has the refresh token, the password no longer matters. The refresh token is the credential. The password the user typed could be reset tomorrow and the attacker would still have the token.

The Token Persistence Problem

Refresh tokens issued through the device code flow inherit their lifespan from tenant policy, which in most Microsoft 365 deployments means weeks or months of validity. That long lifespan is fine when the device holding the token is a smart TV in a conference room. It is catastrophic when the device holding the token is in an attacker's hands.

The article underlines a specific operational gap that defenders frequently miss: password resets do not invalidate refresh tokens. The standard incident response playbook—reset the password, force MFA re enrollment, walk away—does not cut EvilTokens off. The token survives. The only actions that close the access are:

• Explicit revocation of the issued refresh token through the Microsoft 365 admin tooling.
• Conditional access policies that require re consent on a known trigger.
• Disabling the OAuth grant entirely on the affected user.

Most SOC runbooks do not include token revocation as a default step after a credential compromise. The result is incidents that look closed from the user account perspective but stay open from the API access perspective. The attacker keeps reading mail, downloading from OneDrive, and querying the calendar long after the official incident has been resolved.

Why It Is Working Now

Device code phishing is not new. Security researchers have warned about it since at least 2021. The reason the technique has become commercially viable in 2026—why a service like EvilTokens can compromise 340 tenants in five weeks—is that consent fatigue has fully arrived.

A modern knowledge worker sees OAuth consent screens constantly. Every new AI agent asks for permissions. Every browser extension asks for permissions. Every productivity tool, every meeting recorder, every CRM integration asks for permissions. The volume of legitimate consent prompts has trained users to treat the screen as procedural noise. Approve, dismiss, move on.

EvilTokens does not need a clever lure. It needs a plausible cover story for why the user should enter a code: "your meeting transcript service needs reauthorization," "your AI assistant lost session," "your finance team set up a new approval workflow and needs your sign in to test it." Any of those convince a user to enter a code, authenticate, and click Accept. The platform takes care of the rest.

This is the same evolution we covered when ConsentFix v3 demonstrated how Azure CLI OAuth could be abused without any password. EvilTokens is the next generation: a packaged service that productizes the technique and sells it to anyone willing to pay.

What the Attacker Sees

With a refresh token scoped to mailbox, drive, calendar, and contacts, the attacker has the keys to almost everything a user generates inside Microsoft 365:

• Every inbound and outbound email, with attachments.
• The entire OneDrive contents and any shared drive accessible to the user.
• The calendar, including private meeting titles and attendee lists.
• The full contact list with email addresses, phone numbers, and notes fields.
• The ability to send mail as the user, which is how most of these compromises end—the attacker uses the access to phish the user's colleagues from inside the legitimate inbox.

The lateral movement profile is similar to what we saw in the ShinyHunters Salesforce campaign. The first compromised inbox is the launchpad for the next twenty. Every email sent from a real address inside the target organization carries more weight than the same email sent from a spoofed domain. The internal mail relay is doing the social engineering on the attacker's behalf.

What Defenders Can Actually Do

The mitigations exist but they require active deployment, not assumptions:

• Disable the device code flow in tenants that do not need it. Microsoft 365's conditional access policies can block the device code grant outright. Tenants that do not have legitimate device code scenarios should turn it off.
• Audit existing OAuth grants. Every application that holds a refresh token for a user account is a candidate for review. The vast majority of grants in a typical tenant are old, forgotten, and over scoped. Revoke aggressively.
• Build token revocation into the incident response playbook. When a credential compromise is confirmed, the runbook should include explicit revocation of all OAuth grants for the affected user, not just a password reset.
• Alert on new grants for high privilege scopes. The mailbox, drive, calendar, and contacts scopes are exactly what attackers want. A new grant for those scopes should trigger a manual review.
• Train users specifically on device code phishing. The standard "do not click links" training does not cover this. The lure is a code in an email, not a URL. The defense is recognizing that you should never enter a Microsoft device code that you did not initiate from your own device.

The harder part is reframing the user education. The mental model defenders gave users for the last fifteen years was "if it looks like Microsoft, it might not be." EvilTokens flips that: this is Microsoft. The phish is the prompt, not the destination. The destination is legitimate. The threat is the operator on the other end of the device code, not the page rendering on screen.

The Bigger Pattern

EvilTokens is the third major OAuth focused phishing campaign to surface in 2026, after the AccountDumpling Google AppSheet campaign that hijacked 30,000 Facebook business accounts and the Storm-2755 payroll redirect operation. The pattern is consistent. Attackers have stopped trying to crack the front door. They are walking through the OAuth flow with valid credentials handed to them by the user.

Microsoft, Google, and every other identity provider have spent the last decade building MFA enrollment programs that assume the attacker is the one trying to authenticate. The 2026 threat model is the opposite: the attacker is patient, lets the real user authenticate, and collects the resulting token. Until the identity providers ship UX that distinguishes "this device code request is from your own device" from "this device code request is from somewhere else," EvilTokens and its successors are going to keep collecting tenants.