Device Code Phishing Bypasses MFA to Hijack M365 Accounts

A legitimate Microsoft login page. A real authentication prompt. The employee enters a code they received from what looks like their IT department, approves the sign-in, and moves on with their day. Within seconds, the attacker has a fully authenticated access token for that employee’s Microsoft 365 account, including email, SharePoint, OneDrive, and Teams. No password was stolen. MFA wasn’t bypassed. The employee handed over access willingly, because nothing about the process looked wrong.

This is device code phishing, and it has become one of the most effective account takeover techniques targeting businesses in 2025 and 2026. Microsoft attributed active campaigns to the threat group Storm-2372 in February 2025, and researchers have linked similar activity to Midnight Blizzard (APT29), the Russian state-sponsored group behind the SolarWinds attack. The technique has since filtered down to financially motivated threat actors targeting small and mid-sized businesses.

How Device Code Flow Works (and Why It’s Easy to Abuse)

Device code flow is a legitimate OAuth 2.0 authentication method designed for devices that don’t have a browser or a keyboard, like smart TVs, printers, and IoT devices. When a device needs to sign into a Microsoft account, it generates a short alphanumeric code and asks the user to visit microsoft.com/devicelogin on a separate device to enter it. Once the user enters the code and authenticates, the original device receives an access token.

The problem is that nothing in this flow verifies who initiated the code request. The user sees a standard Microsoft login page, enters the code, completes their normal MFA prompt, and approves access. Microsoft handles the authentication correctly, the session token is valid, and MFA is satisfied. The only thing wrong is that the code was generated by the attacker’s machine, not a legitimate device. The access token goes straight to the attacker.

This is what makes device code phishing fundamentally different from traditional credential theft. The attacker never touches the employee’s password. The employee authenticates through Microsoft’s real infrastructure, completing MFA as they normally would. Every security tool watching for stolen credentials, password spraying, or brute force attempts sees nothing unusual. The session is legitimate.

The Attack Step by Step

The typical device code phishing campaign follows a predictable pattern:

1. The attacker generates a device code by sending an OAuth request to Microsoft’s device authorization endpoint. This produces a user code (something like GXF4TPWY) and a device code that the attacker’s system uses to poll for the token.

2. The attacker sends a phishing message containing the user code. The pretext varies: a fake IT support request asking the employee to “verify their account,” a Teams meeting invitation that requires “re-authentication,” or a message from a trusted partner. The message directs the employee to microsoft.com/devicelogin, which is a real Microsoft URL.

3. The employee visits the legitimate Microsoft page and enters the code. Because the page is genuinely hosted by Microsoft, it passes every instinct check. The URL is correct. The SSL certificate is valid. The login experience is identical to any other Microsoft sign-in.

4. The employee completes MFA using their normal method (authenticator app, push notification, or security key). This satisfies Microsoft’s authentication requirements.

5. Microsoft issues the access token to the attacker’s device. The attacker now has an OAuth token, and in most configurations, a refresh token that provides persistent access for days or weeks without requiring re-authentication.

6. The attacker accesses the employee’s account to read email, download files from SharePoint and OneDrive, search for sensitive data, and often set up email forwarding rules to maintain visibility even after the initial token expires.

Device codes expire after 15 minutes, which means the phishing message needs to create enough urgency for the employee to act quickly. Attackers have gotten effective at this, using pretexts like “your account will be suspended” or “confirm your identity to join today’s meeting.”

Why This Hits SMBs Harder

Enterprise organizations with dedicated security teams are more likely to have conditional access policies that block device code flow entirely. Most small and mid-sized businesses running Microsoft 365 Business Premium or E3 licenses have device code flow enabled by default and no policies restricting it.

The attack also scales efficiently. An attacker can generate hundreds of device codes simultaneously and distribute them through bulk phishing campaigns. Each code that gets approved is an immediate, fully authenticated session. There’s no credential database to build, no AiTM proxy infrastructure to maintain, and no session cookies to extract. The employee does the authentication work for the attacker.

For businesses that have invested in MFA and feel confident about their identity security posture, device code phishing is a wake-up call. MFA protects against stolen passwords. It does not protect against a user voluntarily authenticating a session the attacker controls. The Guardz 2026 Threat Report found that 89% of SMBs have at least one compromised user at any given time. Device code phishing adds another path to that number that most security stacks aren’t watching for.

How to Detect and Block Device Code Phishing

Disable Device Code Flow Where You Don’t Need It

The most effective mitigation is to block the device code flow entirely if your organization doesn’t use it. Most SMBs have no legitimate reason for employees to authenticate through device code flow. Microsoft Entra ID (formerly Azure AD) allows administrators to disable the flow through conditional access policies. If your business doesn’t use smart TVs, digital signage, or IoT devices that require this authentication method, turn it off. Your managed IT provider can verify whether any legitimate services in your environment depend on it before disabling it.

Conditional Access Policies

If you can’t fully disable device code flow, conditional access policies can restrict it significantly. Policies can limit device code authentication to specific IP ranges (your office network), require compliant or managed devices, or block it for accounts with access to sensitive data. The goal is to narrow the attack surface so that even if an employee enters a malicious device code, the token grant fails because the conditions aren’t met.

SIEM Monitoring for Device Code Authentication Events

Device code phishing generates specific signals in your Microsoft 365 audit logs. Authentication events using the device code flow show a distinct grant type (urn:ietf:params:oauth:grant-type:device_code) that your SIEM platform can alert on. Correlating these events with other indicators, like the authenticated session immediately accessing email or SharePoint from an unfamiliar IP address, gives your security team a high-confidence detection.

At Infonaligy, our SOC team monitors for exactly these patterns. When a device code authentication event appears from an account that has never used that flow before, followed by access from an unusual location or device, our analysts investigate within minutes. That narrow window between token grant and data access is where the attack gets stopped or succeeds.

Endpoint Detection and Response

EDR on managed endpoints adds another detection layer. If the device code was generated as part of a broader compromise (for example, malware on an employee’s device that automates the phishing chain), EDR picks up the suspicious process activity even if the authentication itself looks clean. EDR also detects the post-compromise activity that follows a successful device code phish: new email forwarding rules being created, bulk file downloads from SharePoint, or lateral movement attempts using the stolen token.

Security Awareness Training

Your employees need to understand that a real Microsoft login page doesn’t guarantee a safe interaction. Security awareness training should specifically cover device code phishing: what the microsoft.com/devicelogin page is, why they should never enter a code they didn’t generate themselves, and what to do if they receive an unexpected request to authenticate. The core rule is simple: if you didn’t initiate the device code request, don’t enter the code. Train your team the same way you train them on credential theft and social engineering, with specific examples of the pretexts attackers use.

Five Questions for Your IT Provider

If you’re unsure whether your organization is exposed to device code phishing, ask your managed IT or security provider these questions:

• Is device code flow disabled in our Microsoft 365 tenant? If no one can explain why it’s enabled, it should be turned off.
• Do our conditional access policies cover device code authentication? Generic MFA policies don’t address this attack. You need policies that specifically target the device code grant type.
• Are we monitoring for device code authentication events in our SIEM? If your managed SIEM isn’t alerting on this grant type, a successful phish generates no alarm.
• Would our SOC detect a token being used from an unfamiliar location immediately after a device code grant? The correlation between grant event and first use is the detection signal. If those events aren’t being linked, the attack looks like a normal login.
• Have our employees been trained on device code phishing specifically? General phishing training doesn’t cover this because the phishing page is a real Microsoft page. Employees need to know what device code flow is and why unexpected code requests are dangerous.

Device code phishing exploits the trust your employees place in legitimate services. The login page is real, the MFA prompt is real, and the authentication works exactly as designed. The only defense is making sure your people know not to authenticate sessions they didn’t start, and having the monitoring infrastructure in place to catch it when someone does.