In April, we wrote about device code phishing as an emerging threat to Microsoft 365 accounts. At the time, it was mostly associated with Russian state-linked campaigns targeting specific high-value organizations. We called it something to watch.

Two months later, it’s something to deal with immediately. Push Security is now tracking 18 distinct phishing kits that include device code functionality. Detections have spiked 37.5x since January. Every major phishing-as-a-service vendor has added it to their platform. What was an espionage technique in early 2025 is now a criminal commodity available to anyone with a subscription.

Why this one is different

Most phishing attacks try to steal your password or intercept your MFA code. Device code phishing doesn’t do either. It exploits a legitimate Microsoft authentication flow designed for devices that don’t have browsers (conference room displays, CLI tools, smart TVs).

Here’s the short version: an attacker generates a device code through Microsoft’s real authentication system. They send you a link to a page that asks you to enter that code. You enter it on a real Microsoft login page. You complete MFA like normal. Everything looks legitimate because it is legitimate, from Microsoft’s perspective.

But the token that gets issued goes to the attacker’s application, not yours. They now have a valid session token for your account. Your MFA worked perfectly. It just authenticated the wrong thing.

What changed since April

Phishing-as-a-service added it to existing platforms. Tycoon2FA, the most popular criminal phishing platform, now offers device code phishing alongside its existing capabilities. That’s like Costco adding a new product line. Overnight, every criminal already running phishing campaigns through Tycoon got a new technique they didn’t have to build themselves.

EvilTokens made it turnkey. A kit called EvilTokens (launched February 2026) provides a complete phishing-as-a-service package specifically for device code attacks. Cloudflare Workers frontend, Railway backend, bot protection to block security researchers, pop-up windows that look like real Microsoft prompts. One of the kits was found to have HTML comments describing its anti-bot features as “ENHANCED ANTI-BOT SYSTEM WITH SERVER-SIDE VALIDATION,” which researchers noted was likely vibe-coded with Claude.

It scaled from espionage to supply chain attacks. The Scattered Lapsus$ Hunters campaign combined device code phishing with social engineering and ended up compromising over 1,000 organizations and claiming 1.5 billion stolen records. That’s not targeted espionage. That’s industrial-scale credential theft.

Why MFA doesn’t help

This is the part that frustrates people. You can have strong passwords, enforce MFA everywhere, even deploy passkeys, and device code phishing still works. It doesn’t attack the login flow. It attacks the authorization layer.

When you enter that device code and complete your MFA, you’re authorizing a token for an application. The attacker controls which application receives the token. Your credentials never pass through the attacker’s infrastructure. Microsoft’s servers handle the entire authentication process normally. The only problem is what happens to the token afterward.

This is why traditional phishing training (“check the URL, look for the lock icon”) doesn’t cover it. The URL is real. The page is real. The MFA prompt is real. Everything about the experience is legitimate except the outcome.

What actually stops it

Block the device code flow by default. In Entra ID (formerly Azure AD), you can create a conditional access policy that blocks the device authorization grant for all users except those who specifically need it. Most office workers never use device code authentication for anything. Block it and the attack doesn’t work.

Restrict which applications can request tokens. Conditional access can limit token grants to approved applications. If an attacker’s application isn’t on the approved list, the device code flow fails even if the user completes authentication.

Monitor for anomalous authentication patterns. Device code authentication from a user who has never used it before, or from a geographic location that doesn’t match their normal pattern, should trigger an alert. Most identity protection tools can flag this.

Update your phishing training. Your team needs to know that legitimate-looking Microsoft login pages can still be part of an attack. The new message: if you receive a link asking you to enter a code on a Microsoft page and you didn’t initiate that process yourself, stop. If someone asks you to enter a code for a “document review” or “account verification,” that’s the attack.

Audit your current conditional access policies. The most common problem isn’t that organizations can’t block device code flows. It’s that they never configured the policy in the first place. The setting exists. Most tenants have it wide open by default.

The trajectory is clear

In January, there were a handful of kits. By March, 15x increase. By June, 37.5x and 18 kits. Tycoon2FA and other major platforms added it to their offerings. The trajectory is clear: this is now standard criminal infrastructure and it’s going to be used in every credential theft campaign that targets M365.

If your M365 tenant doesn’t have a conditional access policy blocking device code authentication by default, that’s the one thing to fix this week. The setting takes five minutes to configure. The exposure it closes is significant.

This is an update to our April post, A New Phishing Attack Targets Your Microsoft 365 Login (and MFA Won’t Stop It), which introduced device code phishing when it was still primarily a state-sponsored technique. It’s now a commodity.

Artech Solutions manages Microsoft 365 security for Iowa law firms and professional services companies. If you’re not sure whether your tenant has device code flows blocked, let us check.