Device Code Phishing Beats MFA on Microsoft 365

Field notes from the engineering team

On October 30, 2026, the security firm LevelBlue published research on a Microsoft 365 phishing kit that does not use a fake login page. The victim signs in on Microsoft’s real page, passes MFA, and the attacker walks away with a live session.

The technique is called device code phishing. It abuses a sign-in method Microsoft built for devices without a keyboard, such as shared devices, digital signage and conference room devices. If your staff use Microsoft 365, this is worth a quick check of your Entra ID settings.

The short version

Item	Detail
What it is	Phishing that abuses the OAuth device code flow in Microsoft Entra ID.
Who is targeted	Microsoft 365 accounts. LevelBlue found more than 70 instances of one kit under at least eight panel names.
Why MFA does not stop it	The victim completes MFA on the genuine Microsoft page. The attacker’s server then receives the tokens.
What the attacker gets	Access and refresh tokens, and in this kit a Primary Refresh Token, used to read the victim’s mailbox.
Main defence	A Conditional Access policy that blocks device code flow. Microsoft recommends blocking it wherever possible.
Second defence	Entra ID sign-in log monitoring and email filtering.

What device code flow is

Anyone who has signed in to a streaming app on a smart TV by typing a short code into a phone has used a device code flow. The TV shows a code. You enter it on a web page on another device, and the TV is signed in.

Microsoft Entra ID supports the same mechanism for Microsoft 365. Microsoft’s documentation describes it as a way to sign in to devices that lack local input, such as shared devices or digital signage. The same documentation calls it a high-risk authentication method that can be part of a phishing attack.

How the attack works

LevelBlue describes the same chain in every lure it collected.

1. A business-themed email arrives. In the two chains LevelBlue collected, it was either a forwarded message with a Google share link or a PDF attachment that led to a shared Microsoft Forms page. Both pass the victim through a trusted cloud service before the lure appears.
2. The lure page shows a code. It is dressed as SharePoint, OneDrive, Zoom, Adobe Acrobat Sign or Excel. The page asks the attacker’s server for a device code and copies it to the victim’s clipboard.
3. The real Microsoft page opens. The button opens microsoft.com/devicelogin in a popup. Everything on that page is genuine. The victim pastes the code and completes MFA.
4. The attacker’s server collects the tokens. It checks every five seconds whether the sign-in finished. When it does, the server holds a live access token and refresh token for the account.
5. The victim sees a normal document. They are sent to a real Microsoft Word page, so nothing looks wrong.

LevelBlue notes that the kit also captures a Primary Refresh Token (PRT), shows it in the operator’s admin panel, and uses it to access the victim’s mailbox. It compares the impact to a Golden Ticket attack in an on-premises Active Directory environment, because a PRT gives single sign-on across integrated applications.

The kit also refreshes its device code after 14 minutes, just before Microsoft’s 15-minute expiry.

One more detail from the research: the researchers assess with high confidence that the kit’s code was largely produced with AI assistance. Their point is that building convincing kits now takes less skill and time. The attack itself still starts with a person clicking a link in an email.

The giveaway on the Microsoft page

The sign-in page tells the user they are signing in to “Microsoft Authentication Broker” on another device. LevelBlue calls that wording the giveaway. The sign-in was started elsewhere by the attacker’s backend, and the victim is only asked to approve it.

That gives staff a simple rule: if a document, a shared link or a web page asks you to type or paste a code into a Microsoft sign-in page, stop and report it. A real document does not need you to sign in on a second page with a code.

What to do

1. Check whether you use device code flow at all. Microsoft’s guidance is to audit current use first, then block it. A Conditional Access policy in report-only mode, or a filter on the Entra sign-in logs for device code flow, shows who uses it.

2. Block it with Conditional Access. Microsoft’s recommended policy targets all users and all resources, sets the Authentication Flows condition to device code flow, and uses the Block access grant. Exclude your emergency access accounts. Start in report-only mode, confirm nothing breaks, then turn the policy on. Conditional Access requires Microsoft Entra ID P1 or higher.

3. Plan for the exceptions. Some Microsoft Teams devices, such as Teams Rooms, use device code flow during registration. Microsoft says to scope any exception to those device accounts and exclude the Device Registration Service resource, not to leave the flow open for everyone.

4. Watch the sign-in logs. LevelBlue advises reviewing Entra ID sign-in logs for unusual deviceCodeFlow events, especially from unmanaged devices, unexpected IP ranges or unfamiliar user agents. Our advice: in a tenant that does not use the flow, any such event deserves a look.

5. If someone entered a code, treat the account as compromised. Microsoft’s guide to revoking access says to block new sign-ins and select Revoke sessions on the user’s page in the Entra admin center. In PowerShell, the command is Revoke-MgUserSignInSession. Our advice: do not stop at a password change, and then check the mailbox for new inbox rules and unexpected forwarding.

6. Tell staff the rule. Do not enter a code that a document or link asked you to enter. Make it easy to report suspicious messages, because an early report can reveal a campaign before any sign-in is abused.

How we help

The block policy is Entra ID and Intune work. We review your Conditional Access policies, check for flows like this one that are left open, and test a new policy in report-only mode before it goes live. Your Microsoft 365 tenant gets the same review for sign-in logging and account settings.

Email security is the first layer. It filters the phishing message before the link reaches a user. No filter catches everything, which is why the identity policy matters. If a sign-in does look wrong, our managed SOC is built to review it, and incident response covers revoking sessions and checking what the attacker touched.

For law firms, healthcare practices and municipalities, a stolen mailbox session can expose client, patient or resident information and become the start of invoice fraud. If you want to know whether your tenant still allows device code sign-in, ask us.

Sources

• LevelBlue SpiderLabs: BlackApex, SPY, and Counting: The Emerging Wave of Vibe-Coded Phishing Kits (October 30, 2026)
• Microsoft Learn: Block authentication flows with Conditional Access policy
• Microsoft Learn: Conditional Access, Authentication flows
• Microsoft Learn: Restrict device code flow for Microsoft Teams devices with Conditional Access
• Microsoft Learn: Revoke user access in Microsoft Entra ID