Storm-2372: Device-Code Phishing
| Attack type | Phishing, token theft |
| Threat actors | Storm-2372, and any actor using device-code or authentication-broker phishing |
| Coverage since | October 20, 2026 |
| Platforms | Microsoft Entra ID, Microsoft 365 |
The user does everything right. They go to a real Microsoft page, enter a code, and complete MFA. The tokens that come back go to the attacker.
The threat
Microsoft's device-code sign-in lets a device without a keyboard — a Teams room, a desk phone, a command-line tool — sign in by showing a short code that the user enters on another device. Device-code phishing turns that around: the attacker starts the sign-in, sends the user the code, and receives the user's tokens when the user enters it.
Storm-2372 builds rapport with a target over WhatsApp, Signal or Teams, then sends a fake Teams meeting invitation whose "meeting ID" is a device code. Since February 2025 the actor has used the Microsoft Authentication Broker, which lets it register a device in Entra ID and keep access long after the first tokens expire.
Why it gets past defenses
- The sign-in is genuine. The user signs in at
microsoft.com/deviceloginand passes MFA. There is no fake page to block and no password to steal. - The lure never touches email. The conversation happens on messaging apps, outside the email security gateway.
- The flow is legitimate. Teams rooms, desk phones and admin tools use device codes every day, so "a device-code sign-in happened" is not an alert on its own.
How Fluency catches it
Fluency separates real device-code use from phishing by what happens after the approval.
- The approval. Every device-code and broker approval is recorded on the user's timeline. A user's first device-code sign-in to an everyday app — Office, Teams, Outlook, the broker — raises a medium alert. Admin tools such as Azure CLI and Azure PowerShell do not.
- The getaway. When the approved session signs in or refreshes its token from a new network in a new country within the hour, Fluency raises a high-confidence alert. A Teams room or desk phone set up with a code signs in from its own network in the same country, so it stays quiet.
- The foothold. When a device is registered to the user minutes after a broker approval and then signs in from a new network, Fluency catches the persistence step too.
Detections included
| Detection | What it catches |
|---|---|
EntraID_DeviceCode_UserApp | A user's first device-code sign-in to an application that is not an admin tool. Medium. |
EntraID_DeviceCode_Phish | A device-code session used from a new network in a new country within an hour. High confidence. |
Office365_Broker_Phish | A broker-approved session used from a new network, or a device registered right after the approval signing in from one. High confidence within the hour, medium for up to 14 days. |
MITRE ATT&CK
| Tactic | Technique |
|---|---|
| Initial Access | T1566.003 Spearphishing via Service (the lure) |
| Credential Access | T1528 Steal Application Access Token |
| Defense Evasion, Lateral Movement | T1550.001 Use Alternate Authentication Material: Application Access Token |
| Persistence | T1098.005 Device Registration |
Get this coverage
The detections are on every Fluency instance. The EntraID_* detections need the Entra ID sign-in logs, collected through Azure Event Hubs or Microsoft Graph; the broker detection needs the Microsoft 365 audit log (Office365 Audit API).
The best defense pairs detection with prevention: block the device-code flow with Conditional Access wherever it is not needed, and Fluency watches the places where it still is.
Not a customer yet? Start a free trial or book a demo.
Related
- Storm-2755: AiTM session theft — stealing the session through a fake sign-in page instead.
- Entra ID Detection Update — the full release, with triage guidance for each alert.