OAuth Device Code Phishing: How Storm-2372 Turned a Legitimate Flow into Token Theft

The OAuth 2.0 Device Authorization Grant, standardized in RFC 8628, was designed for devices that cannot easily display a browser or accept keyboard input: smart TVs, printers, CLI tools, and IoT hardware. It lets a user authenticate on a second device while the constrained device polls for a token. In 2025, attackers realized that the same flow is an excellent phishing primitive. The victim performs a real login on a real identity provider, satisfies MFA, and consents to a real application — and the attacker receives the tokens.

---

1. The Flow in Five Steps

1. The client sends a request to the authorization server's device authorization endpoint with its client_id and requested scopes.
2. The server returns a device_code (secret, long), a user_code (short, human-readable), a verification_uri, and an expiry.
3. The client displays the user_code and instructs the user to visit the verification URI.
4. The user signs in on their phone or browser, enters the code, and approves the request.
5. The client polls the token endpoint with the device_code and receives access and refresh tokens.

Nothing in that sequence is inherently insecure. The weakness is social: the attacker can initiate steps 1 and 2 themselves, then send the user_code and a genuine verification link to the victim. The victim sees a legitimate Microsoft, Google, or Okta domain, completes MFA, and believes they are signing in to a service. The attacker, holding the device_code, polls and receives the tokens.

---

2. Storm-2372 and the 2025 Campaigns

Microsoft Threat Intelligence documented Storm-2372 in February 2025. The actor used device code phishing against Microsoft 365 tenants, targeting government, NGOs, IT services, defense, and telecommunications. The campaign did not exploit a software vulnerability. It abused the device authorization grant with a legitimate client ID, then used the resulting tokens to access mail and other resources.

Because the authentication and MFA happen on the victim's own device and network, the sign-in can appear compliant. The attacker's later use of the token comes from a different location, but the initial authentication event looks like a normal user login. Proofpoint documented additional device code phishing activity in December 2025, confirming that the technique has moved from a novel tradecraft note into repeatable criminal and state-sponsored playbooks.

The core deception: the victim is not giving their password to the attacker. They are giving the attacker a token that the identity provider issued after a successful, MFA-protected login.

---

3. Why MFA Does Not Save You

MFA protects the authentication step. In device code phishing, the victim completes that step correctly. The attacker never sees the password or the one-time code; they receive the output of a successful authentication. This is why the technique is often described as “MFA bypass” even though no MFA control failed. The control protected the login, not the token issuance to an unknown device.

The same logic applies to phishing-resistant authentication. A passkey proves that the human at the victim's device authenticated. It does not prove that the device polling for the token is the same device, or that the user intended to authorize that client.

---

4. Detecting Device Code Authentication

In Microsoft Entra ID, device code sign-ins appear in the sign-in logs with the authentication protocol set to deviceCode. Hunt for:

• Successful device code sign-ins from users who do not use CLI tools or constrained devices.
• Token issuance followed by mail access from a new ASN or country shortly afterward.
• Multiple users receiving device code requests in a short window, suggesting a campaign.
• Consent grants to unfamiliar client applications.
• Refresh token use from a device that never completed an interactive login.

// Microsoft Sentinel / Defender XDR example hunt
SigninLogs
| where AuthenticationProtocol =~ "deviceCode"
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, ClientAppUsed
| order by TimeGenerated desc

Review the client application ID. Attackers often use a first-party or widely known public client so that the consent screen looks familiar. The anomaly is not the app alone; it is the combination of app, user, device, and subsequent access pattern.

---

5. Defensive Controls

5.1 Block device code flow where it is not needed

Microsoft Entra ID Conditional Access supports an “Authentication flows” condition that can block device code flow. Create a policy for all users, with exclusions for the small group that legitimately uses CLI tools or device-based onboarding. This is the highest-leverage control.

5.2 Restrict who can consent

Disable user consent for third-party applications, or restrict it to verified publishers and low-risk scopes. An attacker who cannot obtain consent for a useful client has a much harder path.

5.3 Require compliant or managed devices

A Conditional Access policy that requires a compliant device for mail and file access blocks token replay from an attacker-controlled machine, even if the token was issued legitimately.

5.4 Use token protection and continuous access evaluation

Token protection binds tokens to a device certificate where supported. Continuous access evaluation (CAE) revokes access in near real time when risk changes, such as a password reset or a detected impossible-travel event.

5.5 Shorten token lifetimes and rotate refresh tokens

Reduce the window in which a stolen refresh token is useful. Enable refresh token rotation and reuse detection so that a stolen token used from a second location invalidates the chain.

5.6 Train users on the specific lure

Generic “watch for phishing” training is not enough. Tell users that a legitimate-looking Microsoft or Google page asking them to enter a short code is a red flag unless they initiated the flow themselves. Instruct them to report the message rather than complete the code.

---

6. If a Token Is Suspected Stolen

1. Revoke refresh tokens for the affected user and force re-authentication.
2. Invalidate sessions and review mailbox rules, OAuth grants, and forwarding settings for persistence.
3. Review sign-in and audit logs for the device code event, the token redemption, and subsequent resource access.
4. Check for new application consents and remove any that are not business-approved.
5. Hunt laterally for messages sent from the compromised account containing device codes or verification links.

---

7. Conclusion

Device code phishing is a design consequence of a useful protocol. The flow exists so that a TV can authenticate without a keyboard; attackers abuse it because the verification step is easy to outsource to a victim. The defense is not to disable OAuth or distrust MFA, but to constrain the flow: block it where it is unnecessary, require compliant devices, restrict consent, shorten token lifetimes, and detect the authentication protocol in logs. The victim in these campaigns did everything right at the login screen. The security architecture has to protect them after that screen, when the token leaves the device.