That is exactly what happened at one of our customers, a startup. One morning Exchange flagged suspicious activity on an employee’s mailbox: more than 700 emails had gone out from it to different recipients. The subject was the company’s investment documents, and the link pointed to a domain registered a month earlier, with a subdomain built around the company’s name.
Our team blocked the account, revoked its sessions and reset the password about 30 minutes after the alert. But the sign-in logs showed nothing unusual. The reason: the attacker never signed in with a password. They used the device code flow.
What the device code flow is, and why it gets past passwords and MFA
The device code flow is a fully legitimate way to sign in. It exists for devices without a browser or a usable keyboard, such as smart TVs, IoT devices or command-line tools. The device shows a short code; the user opens Microsoft’s sign-in page on a phone or computer, types the code and signs in. From that moment the first device holds a valid access token.
In device code phishing, the attacker is the "device". They request a code themselves and send it to the victim with a convincing pretext: a meeting invite, a shared document or a secure chat room. The victim goes to the real Microsoft page, enters the code, completes MFA as usual, and the token goes to the attacker.
So no password was stolen, MFA worked as designed, and there is no fake sign-in page for security tools to catch. The attacker keeps access for as long as the tokens are valid.
This isn’t theory. In February 2025 Microsoft published research on a group it calls Storm-2372, running this kind of campaign since August 2024 against governments, organizations and technology companies. According to Microsoft, after the takeover the attackers sent more phishing from the compromised account to other employees, the same pattern we saw at our customer.
The attack, step by step
When we followed the link sent from the customer’s account, this is what we found:
- The lure: an email about a funding round and the company’s investment documents, sent from a real employee’s address, so it looked trustworthy to everyone who got it.
- A first page: the link opens a "slide to verify" page that looks like a normal security check and filters out automated scanners.
- The code: after the check, a code appears with a red "Continue to Microsoft OneDrive" button.
- The real page: the button opens a window with Microsoft’s legitimate device code sign-in page.
- The takeover: the user enters the code and completes sign-in, and the attacker gets an open session on the account.
- The spread: hundreds of emails go out from the compromised account to more addresses, with the same link.
Two more signs stood out. The domain was registered about a month before the incident, a strong phishing signal. And it hosted a subdomain with the company’s name, so the same infrastructure is most likely being used against other organizations.
Why Security Defaults wasn’t enough
The customer had MFA through Security Defaults, the basic, free setting in Entra ID. It is far better than nothing, but it gives you no control: you can’t decide when MFA is required, which devices may sign in, or which sign-in methods are blocked.
In our tests with the customer, MFA was not required on every new sign-in (sign out, sign back in). Security Defaults decides for itself when to ask for a second factor, which makes its behavior hard to predict.
More important: Security Defaults can’t block the device code flow. Only Conditional Access can, and that needs Entra ID P1, included for example in Microsoft 365 Business Premium.
How to defend against it
Microsoft’s own first recommendation is to block the device code flow wherever it isn’t needed. In most organizations nobody uses it, so blocking it goes almost unnoticed.
| Layer | What to do | Why it helps |
|---|---|---|
| Block the device code flow | A Conditional Access policy with the Authentication flows condition that blocks device code for all users, with defined exceptions only | Closes the door this attack walks through |
| Managed, compliant device | A Conditional Access policy that requires an Intune-compliant device to reach company data | The sign-in comes from the attacker’s own, unmanaged device, so Conditional Access refuses it |
| MFA through Conditional Access | Move from Security Defaults to an explicit MFA policy that covers every sign-in | Predictable, consistent behavior with no gaps |
| Email protection | Defender for Office 365 with Safe Links, which checks every link when it is clicked | Lowers the chance the email and link reach the user at all |
| Risk detection | Entra ID Protection with user-risk and sign-in-risk policies | Spots unusual behavior after the takeover and forces re-authentication |
| User awareness | A short training: never enter a code you got by email or message on a Microsoft page | The employee is the last line of defense |
One important point: even phishing-resistant MFA, such as FIDO2 keys or passkeys, does not stop this attack on its own, because the user signs in on the real page. That is why blocking the flow and requiring a compliant device are the critical layers here.
What to do when it has already happened
In an incident like this, time decides how many recipients get hit. These are the steps we took with the customer, in order:
- Stop it now: revoke all of the user’s sessions, reset the password and block sign-in. A password reset alone isn’t enough: revoke the sessions too. Even then, a token already issued can work for up to about an hour.
- Check the scope: run a message trace in Exchange to see how many emails went out, where, and whether other users sent unusual messages.
- Check devices and grants: make sure the attacker didn’t register their own device in Entra ID or grant consent to an app. Microsoft describes attackers doing exactly that to keep access.
- Handle recipients: notify the people who got the email, and inside the organization revoke sessions and reset passwords for everyone who clicked.
- Take the site down: report the impersonating site to the domain registrar and ask for fast removal.
- Talk to the user: find out which links they clicked and what they entered in the week before the incident.
- Close the gap: check that every user is registered for MFA, and move to Conditional Access with the device code flow blocked.
The bottom line
Device code phishing doesn’t steal passwords or break MFA. It uses a legitimate flow that most organizations don’t need and haven’t blocked. One Conditional Access policy that blocks it, plus a managed-device requirement, closes most of the risk. An organization still on Security Defaults can set neither.
Not sure how your tenant is set up? Griffin31 checks your tenant’s security settings continuously and shows you what to fix first.