Device Code Phishing Exposed: How EvilTokens Bypassed Passwords to Compromise 12,000 Mailboxes

Microsoft recently seized a phishing-as-a-service operation called EvilTokens, which successfully compromised approximately 12,000 mailboxes without stealing a single password. It didn't rely on credential theft or brute force — instead, it exploited the OAuth Device Code Flow, an authentication mechanism originally designed for entirely legitimate use cases. This incident exposes a long-overlooked attack surface: when authentication design prioritizes convenience, attackers will exploit that convenience too.

What Is Device Code Login, and Why Is It a Target?

The OAuth Device Code Flow was originally designed for devices with poor input experiences — smart TVs, game consoles, command-line tools, and IoT terminals. These devices often lack keyboards or browsers, making it impractical and insecure to have users enter complex passwords directly on them.

The way it works: the device displays a short code, the user opens a browser on another device (a phone or computer), navigates to a specified URL, enters the short code, and completes the login authorization. The device then receives an access token. Throughout this process, the password never appears on the "thin" device — that's the security selling point.

The problem is that this flow's trust assumption is that "the person entering the short code and the person operating the device are the same person." Once that assumption breaks down, convenience becomes a vulnerability. Attackers don't need to know the victim's password — they just need to trick someone else into completing that authorization step on their behalf.

From the perspective of the OAuth 2.0 protocol specification, the Device Code Flow (RFC 8628) defines two separate polling loops: the device polls the token endpoint at fixed intervals, and the token is only issued after the user completes the action at the authorization endpoint. The critical security assumption in this design is that the "out-of-band channel is secure" — the device delivers the short code to the user via screen or voice, a channel that doesn't traverse the network and is therefore considered trustworthy. When an attacker delivers the short code to a victim via a phishing email, they are effectively hijacking this out-of-band channel: the code shifts from "device tells the user" to "attacker tells the victim," yet the authentication server has no awareness of this. Device codes typically have a default validity period of 15 minutes, giving attackers ample time to carry out the social engineering.

How EvilTokens' Attack Chain Works

EvilTokens turned the trust gap in the Device Code Flow into a scalable attack pipeline. The core logic can be broken down into a few key stages.

The Attacker Initiates the Login

The attacker sends a device code login request to Microsoft's authentication endpoint on behalf of the victim's organization, obtaining a legitimate device code — one genuinely issued by Microsoft. This short code is real, not forged, which makes the subsequent deception extremely convincing.

Disguising the Real Code as a Routine Prompt

The attacker then sends a phishing email or message to the target, typically disguised as a routine IT request — something like "Please complete your multi-factor authentication setup" or "Verify your device" — along with the freshly obtained genuine short code and an official login link. Because the link points to an actual Microsoft page, conventional defenses like checking the domain name are completely ineffective.

The Victim Completes the Authorization on the Attacker's Behalf

Once the victim enters the short code on the official page and completes login using their own credentials (including multi-factor authentication), the token is issued to the device controlled by the attacker. The most insidious part: MFA doesn't block this attack — it becomes an accomplice. The victim personally uses MFA to vouch for the attacker's session.

The attacker receives both an access token and a refresh token, enabling persistent mailbox access for an extended period — all without ever touching the victim's password. As a result, traditional alerts like "suspicious login location" or "credential leak warning" rarely fire.

Why Traditional Defenses Fail Here

What makes this incident worth serious reflection for security teams is that it bypasses nearly every defense organizations typically rely on.

Password policies are irrelevant — no password was stolen. MFA is circumvented — the victim completed it voluntarily within a legitimate flow. The anti-phishing staple of "check the URL domain" doesn't help — the user is genuinely visiting an official domain.

In other words, EvilTokens attacks the logical design of the authentication flow, not a flaw in its technical implementation. Attacks that target protocol trust assumptions are often harder to defend against than those exploiting specific bugs, because patching them means revisiting the tradeoff between convenience and security.

In security research, this type of attack is typically classified as a variant of "Consent Phishing" or "Token Hijacking." A related technique is AiTM (Adversary-in-The-Middle) — where the attacker acts as a transparent proxy between the user and the real authentication server, relaying authentication traffic in real time while intercepting tokens. Device code attacks are even more covert: they require no man-in-the-middle infrastructure whatsoever, leveraging Microsoft's own legitimate endpoints throughout the entire flow. Network-layer protections like TLS certificate validation and HSTS are completely ineffective. This class of attack — targeting "protocol intent" rather than "protocol implementation" — is referred to in academic literature as a "Semantic Attack." It requires defenders to re-examine security boundaries from the perspective of protocol design logic, not just technical vulnerabilities.

How Teams Should Respond

For teams that genuinely need to provide device code login for their users, outright disabling it isn't always realistic — but a series of measures can dramatically narrow the attack surface.

Restrict the scope of the Device Code Flow. If your organization doesn't use smart TVs, command-line tools, or other scenarios that require device codes, disable this flow entirely at the identity platform level. Platforms like Microsoft Entra ID support restricting device code login through Conditional Access policies.

Allowlist on demand, don't open by default. Even where some use cases require it, limit device code login to specific user groups, specific applications, or trusted network ranges — don't leave it open to everyone.

Strengthen token-level monitoring. Since attacks leave no trace of password theft, shift monitoring focus to anomalous token issuance and usage behavior — for example, device code login requests originating from unfamiliar geographic locations or unusual clients.

Update user education on authentication flows. Training content needs a refresh. Don't just teach users to "check the domain" — help them understand this: if they receive a message containing a login short code and they haven't actively initiated a login on some device, they should never enter that code. This is the critical step that breaks the attack's trust assumption.

Conclusion: The Eternal Tug-of-War Between Convenience and Security

The EvilTokens case is a valuable reminder that security threats are shifting from "stealing passwords" to "stealing trust." When authentication mechanisms relax certain assumptions to improve user experience, attackers will precisely exploit those gaps. For teams designing and operating identity authentication systems, the Device Code Flow isn't a feature that must be blanket-disabled — but it does need to be managed as an explicit risk point. Disabled by default, opened on demand, and continuously monitored: that's the more prudent posture.

Background Notes

Access tokens typically have short lifespans (e.g., 1 hour), but refresh tokens can remain valid for days or even months, allowing the holder to continuously obtain new access tokens without requiring the user to intervene again. In Microsoft 365 environments, the default maximum lifetime for a refresh token can be up to 90 days. This means that even if the victim changes their password after the fact, as long as the refresh token hasn't been explicitly revoked, the attacker can maintain access. This is why incident response must explicitly revoke all related tokens — a password reset alone is insufficient to terminate the intrusion.