Device Code Phishing in Microsoft 365: Block It and Spot It in Your Sign-In Logs

This article was written with the help of AI. We used an AI assistant to draft it, then checked the steps against Microsoft's documentation and threat research. Sources are linked throughout.

Device code phishing is one of the few attacks where the sign-in page your employee sees is genuinely Microsoft's. Microsoft's own documentation calls the device code flow "a high-risk authentication method that can be part of a phishing attack" and recommends blocking it wherever possible.

How the Attack Works

The device code flow exists so you can sign in to things without a keyboard, like a conference room screen. The screen shows a short code; you type it at microsoft.com/devicelogin on your phone and sign in there. Attackers abuse it like this:

1. The attacker starts a sign-in on their own computer and gets a code from Microsoft.
2. They send your employee a message, often a fake Teams meeting invite, asking them to enter the code to join.
3. The employee goes to the real Microsoft page, enters the code, and signs in with password and MFA.
4. Microsoft gives the session to the attacker's computer, not the employee's.

Microsoft documented exactly this in a campaign it tracks as Storm-2372, active since August 2024. The attackers used the tokens to search mailboxes for words like "password" and "admin," sent more device-code lures from the compromised account to coworkers, and in a later wave registered their own device in the victim's Entra directory to keep access.

Why Attacker-Registered MFA Is the Real Danger

Once an attacker has a working session, the next move is usually to make it permanent: register their own phone or authenticator app as an MFA method, or join their own device to your directory. After that, a password reset does not lock them out. That is why the second policy below, which controls who can register security info and from where, matters as much as blocking the flow.

Step 1: See Whether Anyone Uses the Device Code Flow

In the Microsoft Entra admin center, open Sign-in logs, add the Authentication Protocol filter and choose Device code. Microsoft suggests this before you block anything. Look at who signed in this way, from where, and to which app. For most small offices the honest answer is either nobody, or one meeting-room device.

When you review a blocked or suspicious sign-in later, the Original transfer method field in the sign-in details shows whether that session started with a device code, even if the current request did not.

Step 2: Block the Device Code Flow

Microsoft's steps, in short:

1. Go to Entra ID > Conditional Access > Policies and select New policy.
2. Include All users. Exclude your emergency access (break-glass) accounts.
3. Under Target resources, include All resources.
4. Under Conditions > Authentication Flows, set Configure to Yes and select Device code flow.
5. Under Grant, select Block access.
6. Set the policy to Report-only, review what it would have blocked, then switch it to On.

If a meeting-room device genuinely needs the flow, Microsoft suggests narrowing the exception, for example to that device type in one network location, rather than leaving it open for everyone.

Step 3: Control Who Can Register MFA

Microsoft's security info registration policy uses the Register security information user action as its target. The template requires users outside your trusted locations to meet an authentication strength before they can add or change MFA methods, and uses a Temporary Access Pass for new hires who have nothing registered yet. That makes it much harder for someone holding a stolen session to quietly add their own phone.

While you are in Entra, check who is allowed to join devices to your directory. Microsoft's Storm-2372 guidance specifically recommends restricting which users can register devices.

Step 4: Look for Signs It Already Happened

• Device code sign-ins from users who have no reason to use them.
• MFA methods added recently, especially from an unfamiliar location.
• Newly registered devices the user does not recognize.
• New inbox rules that move or delete mail.

If you find any of these, revoke the user's sessions, reset the password and remove what does not belong. Our post on Microsoft 365 token replay walks through that clean-up in more detail.

Sources

• Microsoft Threat Intelligence: Storm-2372 conducts device code phishing campaign
• Microsoft Learn: Authentication flows as a condition in Conditional Access policy
• Microsoft Learn: Block authentication flows with Conditional Access policy
• Microsoft Learn: Control security information registration with Conditional Access

Common questions