What this bundle covers
Device code phishing is an OAuth flow inversion. The attacker generates a Microsoft device code on behalf of the victim, serves them a lure page showing that code, and waits while the victim pastes it on Microsoft's real authentication page. The victim authenticates normally — real Microsoft endpoint, real MFA prompt, real FIDO2 hardware key if they use one. When the authentication completes, the attacker receives a full OAuth token set: access token plus a refresh token valid for up to 90 days. No password is ever exposed to the attacker. No credential is stolen.
This is not a new attack class. Storm-2372, the Russian state actor group tracked by Microsoft, used device code phishing broadly against Microsoft 365 tenants before Microsoft began shipping the Conditional Access control that blocks the flow. What changed in 2024 is that Microsoft removed the query-parameter auto-fill that operators were abusing to make the attack zero-click. The floor is higher now. The attack still works. The detection is cleaner. And the one mitigation that actually prevents the flow is a single Conditional Access policy most tenants have never deployed.
The bundle has four parts:
- Threat model. What device code flow is designed for, how the attack inverts it, what the attacker gets, and why phishing-resistant MFA does not help. Read this first.
- Detection. The one Sentinel KQL that catches every successful device code sign-in. Why the false-positive rate is low. What a real attacker event looks like in
SigninLogsversus a legitimate developer workflow. - Mitigations. The CA "Block device code flow" policy, how to configure it, what to allowlist for legitimate use cases, and why admin consent workflow matters as defense in depth.
- Incident response. What to do when you find a device code sign-in you cannot explain. Token revocation, audit log reconstruction, and what an attacker with a 90-day refresh token can do before you catch them.
Who this is for
M365 administrators and SOC engineers who have Sentinel ingesting SigninLogs. The detection is a single analytics rule. The mitigation is a single CA policy. Neither requires a premium license tier above what most organizations already have.
Why we wrote this
We ran device code phishing in a controlled lab against a live Microsoft 365 developer tenant. This bundle is built from what we captured: real SigninLogs rows, real token payloads, real engine behavior. The finding that AuthenticationProtocol == "deviceCode" is the primary detection pivot came from that test. The finding that Microsoft removed ?otc= auto-fill — and what that means for attack friction — came from Playwright probes against four different Microsoft URL variants. The three viable attack architectures post-2024 came from the same lab run.
Status
Published. Threat model, detection, mitigations, and IR runbook are live. The CA "Block device code flow" policy test against rejection telemetry is in progress — that section will be updated when we have the captured enforcement events.