Here’s the verdict first: there’s an active credential-stealing campaign targeting your M365 clients right now, and it survives a password reset. If you haven’t blocked device code authentication flows for your clients, stop reading this and go do that. Come back after.

For everyone still here — let’s break down what’s happening, why it’s nasty, and exactly what to do about it.

What Huntress Found

Huntress spotted this on February 19, 2026, and it’s been accelerating since. Over 340 Microsoft 365 organizations hit across the U.S., Canada, Australia, New Zealand, and Germany. Sectors include construction, healthcare, financial services, legal, real estate, non-profits, and government. In other words: everyone in your SMB portfolio.

The attack is called device code phishing. It exploits a legitimate Microsoft OAuth flow called the device authorization grant — designed for authenticating devices that don’t have a keyboard or browser (think: smart TVs, IoT equipment). Attackers weaponized it because of one key property: the authentication tokens it generates stay valid even after you reset the account’s password.

That’s the thing that makes this different from standard phishing. A compromised password you can fix. A stolen OAuth token? The attacker keeps access until that specific token expires or you revoke it explicitly. Most admins don’t know to look for it.

How the Attack Actually Works

The attacker starts by requesting a device code from Microsoft Entra ID. Microsoft responds with a device code and a URL (microsoft.com/devicelogin). The attacker sends a phishing email to your client’s user — construction bid lures, DocuSign impersonation, voicemail notifications, whatever gets clicks — with the URL and the pre-generated code.

The user goes to the real Microsoft login page, types in the code, enters their credentials and MFA. This is the part that matters: the user authenticates on a legitimate Microsoft URL. No spoofed login page. No suspicious redirect at that step. Microsoft generates valid access and refresh tokens.

The attacker, who has the device code, retrieves those tokens from the OAuth API endpoint. Now they have persistent access to that M365 account.

The email chain Huntress traced routes through Cloudflare Workers redirects before landing on legitimate Microsoft infrastructure. The phishing emails themselves hide malicious URLs inside redirect services from legitimate security vendors — Cisco, Trend Micro, and Mimecast — so they sail through most email filters. Three Railway.com IP addresses drove 84% of the observed authentication abuse events.

Why Your Current Stack Doesn’t Catch This

Anti-phishing filters look for lookalike domains and suspicious redirects. The final authentication is happening on microsoft.com. Clean.

MFA is defeated because the user completes MFA as part of the legitimate device code flow. The MFA code is part of generating the token — and the attacker already has the token.

Password resets don’t help because the OAuth tokens are independent of the password. Reset the password, attacker still has a valid refresh token.

Your SIEM might catch this — if you’re monitoring for unusual sign-ins from unexpected IP addresses, particularly those Railway.com IPs. But most SMB M365 environments don’t have that level of log monitoring.

What You Do Monday Morning

Block device code authentication flows. In Microsoft Entra ID, Conditional Access lets you block the device code authentication method entirely. Most SMB clients don’t have any legitimate use case for it. Microsoft’s guidance on Conditional Access authentication strength covers this. Block it. Done.

Audit existing sessions. For any client you’re worried about, pull the Microsoft Entra sign-in logs filtered by “device code” authentication method. Look for sign-ins originating from Railway.com infrastructure (162.220.234.x and 162.220.232.x). Revoke active sessions for any flagged accounts and force re-authentication.

Token revocation is explicit. If you find a compromised account, don’t just reset the password. Go into Entra ID, find the user’s active sessions, and revoke all refresh tokens. This kills the attacker’s persistent access.

Tighten external email routing. The initial phishing email is what puts users on the path. Work with your email security stack to block redirect chains through third-party security vendor services that don’t originate from those vendors directly. It’s a pain to configure but it cuts off the delivery mechanism.

Add it to your client communication this week. The lures are varied — DocuSign, voicemails, construction bids. Users need to know that any login prompt asking them to visit microsoft.com/devicelogin and enter a code should be verified through you before they proceed. That’s a one-paragraph update to your existing phishing awareness content. Send it.

The Bigger Context

This campaign is running at the same time as the Microsoft Teams vishing surge Danny wrote about today. Two different techniques, same target demographic. Both exploit Microsoft infrastructure. Both bypass standard controls. Neither requires exploiting a software vulnerability.

What that tells you: identity is the perimeter now. Not the firewall, not the endpoint. The attackers have completely internalized this. Most SMB security stacks haven’t.

Huntress’s full technical write-up is worth reading if you want the IOC list and infrastructure details. But the action items above don’t require reading the full write-up. Block device code flows, audit your existing sessions, revoke tokens, update your clients.

Do it before someone on your client list becomes number 341.