Device Code Phishing: The Microsoft 365 Attack Your Security Stack Doesn’t Block

If your business runs on Microsoft 365, there is an attack sitting in your sign-in flow. Most security stacks do not block it by default. It is called device code phishing. It just cost a criminal service called EvilTokens its infrastructure, after the kit was linked to more than 12,000 compromised inboxes at over 10,000 organisations. Here is what the attack does, and what to check this week.

The takedown, briefly

Microsoft’s Digital Crimes Unit went to the US District Court for the Eastern District of Virginia. It won authorisation to seize the infrastructure behind EvilTokens. Health-ISAC joined as co-plaintiff. Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, the Shadowserver Foundation and TRM Labs helped too. Together they took down 50 websites and disabled over 175 domains.

The UK’s Metropolitan Police arrested two men on 11 September, aged 32 and 38, on suspicion of fraud and money laundering. Both are on bail. Investigators, working with Coinbase, traced around $1.1 million in cryptocurrency payments to the operation between October 2025 and June 2026.

None of that undoes the damage already done. And the technique EvilTokens sold is not going away just because one kit is offline.

Understanding device code phishing

Start with what device code sign-in is for. Microsoft, along with other identity providers, built the flow in 2019. It was meant for hardware with no keyboard: a smart TV, a conference-room screen, a command-line tool. A user authenticates it from their own phone instead of typing credentials into an untrusted device. They get a short code and a link, open the link on their own device, enter the code, and the other device signs in.

Criminals worked out they could generate that code themselves. Then they just ask a victim to enter it, through a phishing email, a fake calendar invite or a spoofed Teams meeting request. The victim clicks through to the genuine microsoft.com/devicelogin page. They complete their normal sign-in there, password and MFA included. The page is real and the login is real, so nothing feels wrong. But the code belongs to the attacker’s session, not the victim’s device. The token that gets issued goes straight to the criminal.

Sit with that for a second: MFA does not fail here. It succeeds, on the wrong session. Microsoft says attackers often register a new device within about ten minutes of getting a token. That gives them a Primary Refresh Token and access that survives a password reset.

What made EvilTokens different

Huntress first flagged a device code phishing wave in March 2026. It hit 344 organisations across the US, Canada, Australia, New Zealand and Germany. EvilTokens scaled that idea with automation. Microsoft says an AI assistant built into the kit read through each stolen inbox. It identified who could sign off a payment or a contract, then drafted a convincing follow-up in that person’s style. Microsoft catalogued 44 separate lure themes, from fake invoices and RFPs to document-signing requests and voicemail notifications.

Wholesale distribution, construction, financial services, real estate, higher education and healthcare firms were hit hardest. Victims clustered in the US, Canada, the UK, Australia, India and France. Fortune reports the group later built variants targeting Okta and Gmail too, so this was never just a Microsoft problem.

Once a token landed, Microsoft says attackers used Microsoft Graph to quietly map the organisation. They worked out reporting lines and who held wire-transfer authority. Then they set inbox rules that hid replies from the real account holder, so a business email compromise follow-up could run without the victim noticing. That mix, automated reconnaissance plus a human-sounding follow-up, is what let a small criminal group run at this scale.

A five-point check for this week

First, restrict the device code sign-in flow through Conditional Access. Most organisations do not need it enabled for every account. Scope it to the devices and users that genuinely require it.

Second, move away from telephony-based MFA, SMS and voice codes, towards phishing-resistant methods. FIDO2 security keys and passkeys through Microsoft Authenticator cannot be relayed through a fake sign-in flow the way an SMS code can.

Third, if you suspect a compromise, revoke sign-in sessions and refresh tokens, not just the password. A stolen token keeps working after a password reset unless the session itself is killed.

Fourth, alert on new device registrations that follow shortly after an unusual sign-in. Watch for new inbox rules nobody in IT created too. Both are the fingerprints EvilTokens leaves behind.

Fifth, treat this as a test case, not a one-off patch. A social engineering assessment or a Microsoft 365 security review should probe device code sign-in and inbox rule abuse on purpose. Most vulnerability scanners will not catch either.

None of these five checks is expensive or unusual. What made EvilTokens work for seven months was not a clever new vulnerability. It was a legitimate sign-in flow that almost nobody had reviewed since the day it was switched on. Remember that the next time a security control gets ticked off as “enabled” and never looked at again.