M365 Device Code Phishing Bypasses User Suspicion

How the attack worked

This attack abuses a legitimate Microsoft 365 sign-in mechanism called the device code flow, which is normally used to authenticate devices that lack a browser, such as smart TVs or command-line tools. In this scenario, an attacker initiates the device code flow themselves and generates a code. They then craft an email, often framed as a shared document notification, that pressures the recipient to visit a lookalike site and eventually enter that code at the real microsoft.com/devicelogin page. Because the user is entering the code on Microsoft's own domain and approving a legitimate MFA prompt, Entra ID issues authentication tokens, including refresh tokens, directly to the attacker's polling client rather than to the victim's own session.

Why it succeeded

The core reason this technique works is that every visible signal looks normal to the victim. The MFA prompt is real, the login page is Microsoft's actual domain, and the sign-in itself completes successfully. There is no fake login page to spot and no obviously spoofed domain to flag. The victim believes they are simply confirming access to a shared document, when in reality they are handing over a token that grants the attacker ongoing access. Refresh tokens obtained this way can persist for an extended period, allowing continued access without triggering another MFA challenge.

What to watch for

• Any unsolicited request to enter a device code at microsoft.com/devicelogin, especially when you did not personally initiate a sign-in on another device.
• Emails using urgency language such as warning of consequences if a step is not completed immediately.
• A "document shared" workflow that requires an unusual extra step, like entering a code into a separate login page, rather than a normal access link.
• Sign-in log entries showing the authentication protocol as Device Code, particularly when followed shortly by inbox rule creation or changes.

How to build resistance

Organizations should train employees to treat device code requests as inherently suspicious unless they personally started the device sign-in process. Incident responders need to understand that a password reset alone does not revoke refresh tokens, so token revocation must be treated as its own deliberate response step. Security operations teams should build monitoring around the Device Code authentication protocol in Entra sign-in logs and correlate those events with subsequent mailbox rule changes, since this combination is described as one of the highest-fidelity indicators of follow-on business email compromise activity.

What is device code phishing in Microsoft 365?

It is an attack where a victim is tricked into entering an attacker-supplied code at the real microsoft.com/devicelogin page, causing Microsoft 365 to issue login tokens to the attacker's session instead of the user's own device.

Why does this attack bypass user suspicion?

The victim completes a genuine sign-in on a legitimate Microsoft URL and approves a real MFA prompt, so from the user's perspective nothing looks wrong.

Does resetting a password stop this attack?

No, a password reset alone does not revoke an active refresh token; explicit token revocation is a separate step defenders must take.

How can defenders detect device code phishing?

Defenders can look for sign-ins where the authentication protocol is Device Code in Entra sign-in logs, and correlate these with subsequent mailbox rule changes or location mismatches.