OAuth 2.0 Device Code Phishing Surge: Protecting M365 and Google

Threat actors are increasingly shifting away from traditional credential harvesting in favor of sophisticated session hijacking techniques. A significant development in this space is the 3,700% increase in attacks abusing the OAuth 2.0 Device Authorization Grant flow, according to BleepingComputer. These campaigns effectively bypass multi-factor authentication (MFA) by tricking users into authorizing malicious login requests on legitimate platforms.

Surge in Device Authorization Grant Exploitation

The OAuth 2.0 Device Authorization Grant (RFC 8628) was designed for devices with limited input capabilities, such as smart TVs, IoT hardware, and command-line interfaces. Because these devices cannot easily display a standard login page, the protocol allows them to generate a ‘User Code’ and a ‘Verification URI’. The user then visits the URI on a separate device (like a smartphone or laptop) to approve the request.

Adversaries have recognized that this mechanism provides a path for Phishing that circumvents modern security controls. In these campaigns, an attacker initiates a device code request for a target service, such as Microsoft 365. They then send the generated code to a victim via email or chat. When the victim enters the code at a legitimate URL—such as microsoft.com/devicelogin—they are essentially performing the authentication on behalf of the attacker. This process completes the MFA challenge for the attacker, who then receives a valid session token.

Technical Analysis: The Device Code Flow Abuse

The primary advantage for the attacker is that the victim interacts only with the legitimate service provider’s domain. Traditional EDR solutions and browser-based protections often fail to flag these interactions because no malicious domains are visited during the authentication phase. This TTP leverages the inherent trust users have in official Microsoft or Google login portals.

Once the victim authenticates, the attacker’s C2 or phishing kit automatically polls the token endpoint. Upon successful authorization, the kit receives an access token and a refresh token. These tokens allow the attacker to maintain persistence and perform Privilege Escalation or Lateral Movement within the organization’s cloud environment. Tools like ‘TokenTactics’ and ‘DeviceCodePhish’ have simplified this process, making it accessible to less sophisticated threat actors.

How to Detect Device Code Phishing in Enterprise Logs

For a SOC analyst, identifying these attacks requires a shift in monitoring strategy. Security teams should integrate their SIEM with identity provider logs to track specific authentication methods. In Microsoft Entra ID (formerly Azure AD), analysts should monitor the Sign-in logs for the Authentication Method property. Any successful sign-in where the method is ‘Device Code’ should be scrutinized, particularly if it originates from an unexpected IP address or an unmanaged device.

IoC identification in these cases is difficult because the initial request comes from the attacker’s infrastructure, but the authorization comes from the victim’s. Security professionals should map these activities against the MITRE ATT&CK framework, specifically focusing on sub-technique T1528 (Steal Application Access Token).

Mitigation and Defense Strategies

Defending against these surges requires a combination of technical controls and user education. The most effective Microsoft 365 device code phishing mitigation is the implementation of Conditional Access (CA) policies. Organizations should configure CA policies to block the device code flow entirely unless it is specifically required for verified business processes. If the flow is necessary, it should be restricted to ‘Known’ or ‘Compliant’ devices only.

Additionally, adopting a Zero Trust security model ensures that no single authentication event is trusted implicitly. Identity teams should also consider implementing ‘Continuous Access Evaluation’ (CAE) to revoke sessions immediately if a change in location or device posture is detected. Regular training should emphasize that users should never enter a code into a device login page unless they manually initiated the request themselves on a secondary device.