Device Code Phishing Bypasses MFA to Hijack Microsoft 365 Accounts Stealthily

MFA was supposed to be the control that finally slowed down account takeovers. For a while, it worked. Then attackers stopped trying to steal passwords and started stealing sessions instead, and the newest way to do that doesn’t need a fake login page, a cloned domain, or a single stolen credential. It just needs a victim willing to type a code.

The device authorization grant in OAuth 2.0 exists to solve a real problem: how do you sign into a smart TV, a conference-room system, or a CLI tool that has no keyboard or browser? The answer is a short code.

The device displays it, the user opens a second screen, enters the code on a legitimate Microsoft page, and approves. Tokens flow back to the device that requested them.

Device Code Phishing Bypasses MFA

That last step is the entire attack surface. In a legitimate flow, the device requesting the code and the person approving it are the same party. Device code phishing breaks that assumption by inserting an attacker between the two.

The attacker’s server initiates a real device-code request against Microsoft and receives a genuine, short-lived code. A lure, often a “shared document” or “verify your account” email, delivers that code to the victim with a believable reason to use it. The victim goes to the real Microsoft sign-in page, enters the code, authenticates, and completes MFA exactly as designed.

Because the victim approved the attacker’s pending request rather than their own, Microsoft issues the resulting tokens to the attacker’s infrastructure. No password was phished. No proxy site relayed the session. MFA was satisfied for real, just for the wrong party.

According to TrendMicro, once the attacker holds valid tokens, targeting the Microsoft Authentication Broker lets a single approval escalate into something durable: registered rogue devices and long-lived refresh tokens.

That’s the real danger: this isn’t a one-time login; it’s persistent access that survives password resets and often outlives casual detection efforts. In observed cases, attackers used this foothold to register devices, sign into Outlook, create hidden mailbox rules, and launch further phishing campaigns all without ever touching the victim’s endpoint.

Because the attack lives entirely in the identity layer, that’s where defenders need visibility:

Device-code sign-ins, which should be rare in most tenants and easy to flag as anomalous
Authentication Broker activity from unfamiliar countries, networks, or unmanaged devices
Spikes in new device registrations within short windows
New inbox rules that hide, delete, or auto-forward mail
Sign-ins that don’t match a user’s normal travel or work patterns
Awareness first: Train users that any unsolicited request to enter or read a code is suspicious, and give them a fast way to report it.
Block the flow: Disable the OAuth device-code flow via Conditional Access wherever it isn’t genuinely needed, with narrow, documented exceptions.
Restrict device registration: Limit who can register devices, require compliance for mail access, and cap per-user device counts.
Harden identity controls: Enforce named-location policies, enable Continuous Access Evaluation and token protection, and auto-revoke sessions on elevated risk.

Device code phishing doesn’t exploit a bug; it exploits trust in a legitimate flow, a real login page, and a convincing story. That combination is exactly why it slips past defenses built around passwords and endpoint monitoring. The fix isn’t more MFA; it’s recognizing that identity infrastructure itself is now the primary attack surface.