Device code phishing let a Russian state hacking crew skip stealing passwords entirely. It walked straight into business travelers’ Microsoft 365 accounts instead. Microsoft’s Threat Intelligence team says the technique comes from Storm-2945, a Midnight Blizzard sub-cluster. It has run from hijacked hotel Wi-Fi since 16 July, layered on top of a malware campaign active since May.
Anyone running an Entra ID tenant needs to know how this device code phishing trick works. The fix isn’t a patch or an alert rule. It’s a configuration change most tenants haven’t made.
What device code phishing actually does
Microsoft built the device code flow for devices without a browser, like a smart TV or a conference room console. You visit microsoft.com/devicelogin on your phone, type in a short code shown on the other device, and sign in normally. It’s a legitimate feature, and that’s exactly what makes it useful for phishing.
The flow was never designed with an adversary-in-the-middle scenario in mind. It assumes the person requesting the code and the person entering it are the same user, on two devices they both control. Storm-2945’s whole trick is breaking that assumption. The request comes from the attacker. Only the entry comes from the victim.
Storm-2945 flips the order. Its captive portal landing page requests a device code on the attacker’s behalf. It shows that code to the victim, framed as a step in a fake update or verification process. The victim types that code into a real Microsoft sign-in page and completes MFA themselves. They don’t realize they’ve just authenticated the attacker’s session instead of their own device.
Because the login page is genuine and the MFA prompt is real, most user training doesn’t catch it. There’s no fake password field to spot, no lookalike login screen. The phishing happens entirely inside the authentication flow itself.
How it fits the wider campaign
Before adding device code phishing, the same hijacked networks pushed a ClickFix-style lure. A fake Windows or browser update told victims to paste a command into Windows Terminal. That step installed one of two tools: CornFlake, a Go-based RAT, or ChocoShell, an in-memory PowerShell infostealer. ChocoShell specifically targets Microsoft 365 and Azure AD tokens straight from the Windows Token Broker cache. Both report to a panel called FruitStone. The device code trick is a second, quieter path to the same prize: a corporate cloud account.
Microsoft also notes technical overlap between Storm-2945 and Storm-2372. It has tracked Storm-2372 separately for device code and OAuth phishing against cloud tenants. In other words, this isn’t an improvised addition. It’s an established technique from elsewhere in the Midnight Blizzard umbrella. Here it’s redeployed onto a delivery channel, hotel Wi-Fi, that most security teams simply don’t monitor.
How to check if you were hit
Start with sign-in logs rather than endpoint alerts. A successful device code phishing attempt won’t necessarily trigger malware detection.
- Search Entra ID sign-in logs for device code flow authentications from unfamiliar IPs or client apps, especially from users who traveled recently.
- Cross-reference sign-in times against travel or expense records for hotel or conference stays since May.
- Hunt for the published indicators: domains including ms365-device[.]com, ms365-live[.]com, m365-owa[.]com and owa-ms365[.]com, plus the CornFlake and ChocoShell file hashes in Microsoft’s report.
- Look for a Windows service named svchost32 with the display name “Cloud Sync Service”, which is CornFlake’s persistence mechanism.
- Watch for outbound traffic resembling tracking-pixel requests to a path like /t/pixel.gif?m=, one of ChocoShell’s callback patterns.
How to close the gap
The fix here isn’t better awareness training. Nothing on the sign-in page looks wrong, so no amount of “check the URL” advice helps against this kind of device code phishing. The fix is removing the flow attackers rely on, then hardening what’s left.
- Disable the device code authentication flow in Conditional Access unless a specific, documented business case needs it. Then scope it tightly to those accounts.
- Move admins and other privileged users to phishing-resistant MFA, such as passkeys through Microsoft Authenticator. A one-time code doesn’t help when the victim is authenticating the wrong session.
- Turn on continuous access evaluation and sign-in risk policies so a session created from an unusual location gets challenged again rather than trusted indefinitely.
- Deploy a Security Service Edge tool, such as Microsoft’s Global Secure Access, to route traveling staff through a controlled path instead of trusting whatever network they land on.
- For staff who travel often, issue a cellular hotspot or a managed travel router instead of relying on hotel and conference Wi-Fi.
None of this needs new tooling if you’re already running Entra ID and Defender. It needs someone to actually turn the device code flow off for the accounts that don’t use it. Then check who authenticated through it while it was on. Defender also carries a detection for this cluster’s activity, but it fires after the fact. The Conditional Access change is what stops the technique from working at all.
This only works because the sign-in page really is genuine. Blocking the flow entirely is the only control that doesn’t depend on a distracted traveler getting it right. Hoping staff notice something off isn’t a plan.