The Login Code That Walks Past MFA

A legitimate Microsoft sign-in feature, built for smart TVs and command-line tools, has become one of the most dependable ways to take over a Microsoft 365 account without stealing a password or defeating a single MFA prompt.

Enable multi-factor authentication and most account takeovers stop. That guidance has held up well for a decade, and it still does against the threat it was written for: a stolen or guessed password. The trouble is that a growing class of attacks does not want the password. It wants the session that MFA produces, and it has found a way to have the legitimate user hand that session over.

Device-code phishing is the clearest example. Over the past year it has slid from the exclusive toolkit of nation-state operators into off-the-shelf phishing-as-a-service kits, and it now ranks among the most reliable routes into a Microsoft 365 tenant. What makes it unsettling is how ordinary each step looks. The victim lands on the real Microsoft sign-in page, answers a genuine MFA challenge, and sees every indicator of a normal, successful login. The session that results is issued to the attacker anyway. Nothing is stolen, nothing is bypassed. The user simply approves the wrong device.

The sections below cover the mechanics of the flow, why the usual anti-phishing controls have nothing to grab onto, and the Entra ID configuration and detection signals that actually change the outcome.

How the Attack Works

Device-code authentication is not a bug or an obscure corner of the protocol. It is a defined part of the OAuth 2.0 Device Authorization Grant, and it exists for a practical reason: some devices cannot present a usable browser. A smart TV, a printer, a command-line tool, or a piece of IoT hardware cannot reasonably ask a user to type a password and complete MFA on its own screen. So instead it shows a short code and asks the user to finish signing in from a phone or laptop. Approve there, and the device receives its tokens. The design is genuinely useful, which is exactly what makes it worth abusing.

The five-step sequence

The attacker's move is to turn the trust relationship around. The flow was meant to let a person authorize their own hard-to-use device. Instead, the attacker starts the flow against the target's tenant and gets a real user to complete the approval on the attacker's behalf:

The attacker asks Microsoft's legitimate endpoint for a device code and receives a valid user_code and device_code.
A lure carries that code to the victim. It might be a Teams meeting invitation, a shared-document notice, or an invoice that asks them to confirm identity at the genuine microsoft.com/devicelogin page.
The victim signs in and clears their normal MFA challenge on Microsoft's own site. From where they sit, the request is unremarkable.
Throughout, the attacker is polling Microsoft's token endpoint. Approval flips the poll from pending to complete, and Microsoft returns valid access and refresh tokens directly to the attacker's session.
The victim gets a bland confirmation or a redirect and moves on. The attacker is now authenticated inside the tenant with a session that MFA has already blessed.

A simplified flow

Sequence diagram of device-code phishing: the attacker requests a device code from Microsoft, lures the victim into entering it and completing genuine MFA, polls the token endpoint, and receives the victim's access and refresh tokens into the attacker's own session — Device-code phishing: the victim authenticates on Microsoft's real page, but the resulting session is issued to the attacker

Every authentication step happens on Microsoft's own infrastructure, and that is the whole point. There is no counterfeit login page to spot, no lookalike domain to blocklist, and no stolen password sitting in a database waiting to be reused. Microsoft Threat Intelligence has been explicit that this is not a flaw in their code. It is a standards-based feature working precisely as specified, aimed at the wrong person.

Why Traditional Defenses Miss It

Most anti-phishing tooling is built to notice one of three things: a shady domain, a harvested credential, or a second factor that got skipped. Device-code phishing serves up none of the three.

Domain and URL filtering watches the user visit login.microsoftonline.com. That is the real destination, so there is nothing to flag.
Credential-theft detection has no event to fire on, because the password is entered on Microsoft's page and never touches the attacker.
MFA is not evaded so much as fulfilled. The real user completes the challenge, so the sign-in record reads as fully compliant.

The more serious issue is the prize. What the attacker collects is a refresh token, and a refresh token is not a single login that expires when the user next authenticates. It is durable access that outlives a password reset and survives routine MFA re-prompts. This is why responders who reset a compromised user's password sometimes find the intruder still active hours later. The problem deepens when the attacker aims the flow at the Microsoft Authentication Broker client, because a single approval can then be parlayed into a registered rogue device and a Primary Refresh Token (PRT). At that point a one-time phish has become device-level persistence.

Durability plus invisibility explains why the technique has proliferated. It surfaced first in state-aligned operations. Microsoft attributes an early and sustained campaign to Storm-2372, a Russia-aligned cluster active since August 2024 that used fake Teams, Signal, and WhatsApp invitations against government, defense, energy, and NGO targets. Since then the method has been packaged into ready-made kits that generate their lures with AI and automate the token capture, so it is no longer a problem reserved for the most advanced adversaries.

CyopScape Lab Note

Hunting device-code sign-ins in Entra ID

In most tenants, genuine device-code authentication is uncommon, and rarity is what makes it worth hunting. Entra ID labels the authentication protocol directly in its sign-in logs, so one filter is enough to surface every use of the flow across the environment.

Entra ID sign-in logs · KQL

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| project TimeGenerated, UserPrincipalName, IPAddress,
          Location, AppDisplayName, ResourceDisplayName

Treat a result as a lead, not a verdict. Command-line tooling and some onboarding workflows use device code legitimately, so the payoff is in the pivot. Take a questionable sign-in, follow the session it produced, and look for activity that does not match the user:

Microsoft Graph calls firing minutes after the sign-in, such as bulk mailbox reads, OneDrive enumeration, or a freshly created inbox rule
A device registration event landing right after the approval, which is the tell for PRT-based persistence
A gap between where the code was approved and where the resulting token is used, whether by geography or by IP

When a session does look compromised, the action that counts is revoking the refresh token itself. Resetting the password on its own leaves the token valid.

Defensive Takeaways

Since the attack rides on a sanctioned feature, the defenses that work are the ones that constrain or watch that feature, rather than the ones that try to catch the phish on its way in.

Turn the flow off where nobody uses it

The device-code flow ships enabled and, in most tenants, sits unrestricted even though almost no one has a legitimate need for it. A Conditional Access policy that blocks device-code authentication for everyone except a named set of users and devices removes the attack surface rather than trying to police it. Microsoft's own recommendation is to block the flow where you can and scope it tightly with Conditional Access where you cannot.

Move toward phishing-resistant MFA

Passkeys and FIDO2 security keys tie authentication to a specific device and origin. That binding is what closes the gap device-code phishing exploits, because a challenge satisfied on the right device can no longer be redirected into an attacker's waiting session.

Shorten the token's useful life with CAE and risk policies

Continuous Access Evaluation lets a revoked refresh token stop working within minutes instead of lingering until its natural expiry. Combined with sign-in risk detections, such as anomalous token, unfamiliar sign-in properties, and known threat-actor IPs, it narrows the window in which a stolen session is worth anything.

Alert on device registrations and inbox rules

A new device registration and a newly created inbox rule are among the cleanest signs of post-compromise activity. Alerting on both catches the step where an intruder converts access into persistence, even in cases where the original sign-in looked entirely legitimate.

Give users a single rule they can remember

The human side of this defense is refreshingly simple: an unsolicited login code is an attack. No genuine service sends a code and then asks you to type it in to "join a meeting" or "verify" yourself. One rule, stated that plainly, defuses most lures before the token is ever issued.

Final Thoughts

Device-code phishing is a case study in a wider truth: the attacks that last are often not exploits at all, but legitimate features turned against the people they were designed to help. You cannot patch a design that is behaving as intended. The response is to constrain the feature, watch how it is used, and treat long-lived tokens with the same seriousness you would give any other set of keys to the environment.

There is a habit of mind worth taking from this too. Identity defense has spent years teaching us to trust a clean sign-in record, and device-code phishing shows why the cleanest record is sometimes the one that deserves a second look. When authentication succeeds without a hitch but the session that follows behaves like a stranger, the tidy log entry is not reassurance. It is the incident.

← Back to Insights