Device code phishing: why a legitimate Microsoft URL isn't proof of anything

Kaspersky's Securelist team recently published research on phishing campaigns that skip the fake-domain step entirely. Victims are walked through a real, unmodified login.microsoftonline.com login and MFA prompt, and they still hand over their account.

The trick is the Device Authorization Grant (device code flow), an OAuth 2.0 extension built for input-constrained devices like smart TVs and streaming boxes. Since the victim never types a password into a look-alike site, "check the URL bar" style training does not catch it.

How the attack works

Attacker fetches a device code. The attacker's own script calls https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, requesting whatever scopes it wants (Mail, Files, Teams). Microsoft returns a short-lived user_code and a verification_uri.
The lure hides behind a trusted redirect. In the campaigns Kaspersky observed, victims received a law-firm-styled email with a password-protected PDF, or a message pointing to a legitimate diagramming site (cacoo.com). Both used open redirects on trusted domains to land on attacker-controlled phishing pages, so the visible link at first glance was legitimate.
The phishing page hands over a "copy code" button. After a CAPTCHA wall (likely to filter automated scanners), the page shows the user_code and a button that copies it and redirects the victim straight to Microsoft's real device login page.
The victim completes real MFA, on the real site. Because the login page is genuinely microsoft.com/devicelogin, there's nothing to spot. The victim pastes the code, approves the sign-in, and passes MFA themselves.
The attacker now holds the tokens. Microsoft issues an access_token, refresh_token, and id_token to the attacker's polling script, not the victim's browser. The refresh_token lets the attacker keep renewing access to mail, OneDrive, and Teams long after the initial click.

The result is functionally an MFA bypass: the attacker never needs the victim's password or a code interception, they just need the victim to approve a device sign-in they didn't initiate.

What to check in your tenant this week

Do you actually need the device code flow? Most organizations don't have smart TVs or kiosk hardware authenticating against Entra ID. If nothing in your environment legitimately depends on it, disable it via Conditional Access policies targeting the device code authentication flow.
If you can't disable it outright, restrict it. Scope device code sign-in to specific apps, named locations, or compliant devices only, rather than leaving it open tenant-wide.
Turn on monitoring for DeviceCodeSignIn events. Alert on device code approvals from users or locations that have no business reason to use the flow, and treat a spike in device code sign-ins as an incident trigger, not noise.
Update phishing awareness training. "Check the domain" is not sufficient guidance anymore. Add the specific scenario: never approve a device sign-in code you did not personally initiate on a TV, kiosk, or similar device, even if the page asking for it is microsoft.com.
Watch for open-redirect abuse on your own trusted domains. The campaigns used redirect_uri and similar parameters on legitimate third-party sites to bounce victims to phishing infrastructure. If you operate a service with an open redirect, threat actors can borrow your domain's reputation the same way.

Why this matters beyond Microsoft

The device code flow is an OAuth 2.0 standard, not a Microsoft-specific quirk. Any identity provider that supports it is a candidate for the same abuse pattern. If your organization uses other platforms with device authorization grants, the same detection and restriction logic applies: audit whether the flow is needed, restrict it if it is, and alert on anomalous use if you can't turn it off.

Need help closing this gap?

If you want a hand auditing Conditional Access policies, scoping device code flow, or building detection for anomalous sign-ins, contact us.