Device Code Phishing Explained: How Attackers Abuse OAuth Across SaaS

Phishing campaigns continue to evolve. As organizations strengthen credential-based defenses with MFA, password managers, and phishing-resistant authentication, attackers have shifted their focus from stealing credentials to stealing OAuth tokens. One of the most consequential examples of this shift is device code phishing, an attack pattern that abuses a legitimate OAuth 2.0 authentication flow to obtain valid access and refresh tokens without needing the victim’s password and without triggering the protections that defeat traditional phishing.

At AppOmni, we recently published an analysis of the EvilToken phishing-as-a-service kit and the AI-driven campaign documented against Microsoft 365 tenants. That campaign demonstrated the scale this attack class has reached. Researchers tracked 10 to 15 distinct waves every 24 hours at peak, more than 7 million device code attacks were observed in a single four-week window, and one wave compromised over 340 organizations across five countries.

EvilToken and the Microsoft 365 campaigns, however, represent one chapter in a broader pattern. Device code phishing is a protocol-level technique that applies to any platform implementing the OAuth 2.0 Device Authorization Grant, and attackers are systematically iterating across the SaaS ecosystem. The campaigns observed against Salesforce, GitHub, and other services demonstrate that this is not a Microsoft-specific issue. This post focuses on the broader landscape, the campaigns observed against non-Microsoft platforms, and the platforms most likely to be subject to this attack class.

Key takeaways

• Device code phishing abuses legitimate OAuth authentication flows to steal access and refresh tokens, allowing attackers to gain persistent access without stealing passwords.
• Multi-factor authentication (MFA), passkeys, and phishing-resistant authentication do not fully stop device code phishing because victims complete authentication on the legitimate identity provider.
• Attackers have expanded device code phishing beyond Microsoft 365, targeting platforms such as Salesforce and GitHub and demonstrating that the technique applies across the broader SaaS ecosystem.
• Traditional email, URL reputation, and adversary-in-the-middle defenses often miss these attacks because they rely on legitimate vendor URLs and trusted OAuth workflows.
• Security teams should focus on visibility into OAuth grants, connected applications, consent activity, and token usage patterns rather than relying solely on credential-focused defenses.
• Even when vendors restrict or remove device authorization flows, attackers can shift to other OAuth authorization methods, making continuous monitoring of SaaS identities, permissions, and connected applications essential.

How device code phishing works

OAuth 2.0 includes a flow called the Device Authorization Grant (RFC 8628). The use case is straightforward: how does a user sign into an application on a device that has no keyboard or browser, such as a smart TV, an IoT device, or a command-line tool on a remote server. The flow works in four steps:

1. The device asks the identity provider for a short code.
2. The IdP returns a code and a verification URL.
3. The user opens the URL on a phone or laptop, signs in with their normal credentials, including MFA, and approves the request.
4. The IdP issues an access token and refresh token to the original device.

The flow is legitimate and works exactly as designed. The problem is that step 3 provides the user with no information about what device is being authorized. The requesting device could be a Smart TV running a streaming application, a CLI tool that needs to call an API, or a malicious script controlled by an attacker on a remote server. From the user’s perspective, the three are indistinguishable.

The victim sees a code. They enter it on the legitimate verification URL. They complete MFA on real infrastructure. The result is a valid access token and refresh token issued to a party they have never seen.

From a defensive standpoint, this is a difficult attack pattern to detect. There is no fake page, no proxy, and no spoofed domain. Email security gateways do not flag the link because it points to a legitimate vendor URL. URL reputation feeds have no malicious indicators to surface. Adversary-in-the-middle detection sees nothing because there is no man in the middle. The attacker impersonates the device, not the user, and the IdP has no mechanism to differentiate between them.

Why MFA does not stop this attack

The standard defensive model for phishing relies on training users not to click suspicious links to defeat classic phishing and requiring phishing-resistant MFA. Device code phishing routes around all of that.

MFA provides no protection because the victim performs the MFA challenge themselves, on the real IdP, in their normal browser. They are not bypassing the challenge. They are completing it correctly, on behalf of an attacker.

FIDO2 and passkeys reduce the attack window but do not close it. The FIDO challenge is real, and the IdP genuinely authenticates the user. From the IdP’s perspective, the flow is legitimate end-to-end. The only thing that is malicious is who is requesting the token, and the IdP has no way to know.

Password resets do not revoke the session. The refresh token issued through the device flow remains valid for an extended period, often weeks or months depending on the platform’s default token policy. The victim may change their password, but the attacker retains access. This persistence makes incident response significantly more complex than for a typical credential compromise.

Campaigns beyond Microsoft 365

While Microsoft 365 has dominated the recent reporting, the same playbook has been adapted and reapplied to other platforms. The pattern across these campaigns is consistent: identify a SaaS platform that supports OAuth device flow, tailor the social engineering to that platform’s specifics, and execute. The technique itself is platform-agnostic, and the campaigns observed in the past 18 months show that attackers are systematically working through the SaaS ecosystem.

Storm-2372 establishes the modern playbook

Storm-2372, a Russia-aligned threat actor first publicly named in February 2025, targeted Microsoft 365 tenants across government, NGOs, defense, telecommunications, healthcare, higher education, and energy sectors in multiple regions, with activity observed since August 2024. While Storm-2372’s targeting was Microsoft-specific, the group established the playbook that subsequent campaigns extended to other platforms. Lures impersonated Microsoft Teams, WhatsApp, and Signal chat invitations, with every link pointing to legitimate vendor URLs that traditional email security controls did not flag. The same approach has since been adopted by financially motivated actors and applied across other SaaS platforms.

Scattered Lapsus$ Hunters and the Salesforce supply chain

The most damaging non-Microsoft device code phishing campaign of the past year targeted Salesforce.

Scattered Lapsus$ Hunters is an alliance of three cybercrime groups: Scattered Spider, ShinyHunters, and the original LAPSUS$. The campaign combined voice phishing with device code phishing in a pattern that proved highly effective against Salesforce customers.

The approach was direct. Attackers placed phone calls to victims posing as IT helpdesk staff, citing an authentication issue that required verification. The victim was walked through entering a device code on Salesforce’s /setup/connect page. Once entered, the victim was prompted to authorize what appeared to be Salesforce’s own legitimate Data Loader connected app. With the attacker on the line and the consent screen showing a trusted vendor name, the social pressure to approve was high.

The group claimed 1,000+ organizations compromised and approximately 1.5 billion records stolen. Named victims included KLM Air France, Adidas, Qantas, and Allianz Life. As with any threat-actor self-reporting, the exact figures should be treated with caution, but the underlying campaign was real and substantial in scope.

Salesforce responded by removing OAuth 2.0 device flow entirely in September 2025, with no exceptions or extensions for affected customers. This is one of the most decisive vendor responses to a specific OAuth abuse pattern in the past several years.

Device code phishing against GitHub

Public security research has documented device code phishing techniques against GitHub with reported success rates above 90% in authorized engagements. Public adversary attribution against GitHub specifically remains thinner than the reporting on Microsoft 365 or Salesforce, but the implications for supply chain risk are significant.

When an attacker phishes a GitHub OAuth token with broad scope, they obtain access to the victim’s private repositories, GitHub Actions secrets, and the ability to modify CI/CD pipelines. For developers with access to widely-depended-on open source projects or critical internal repositories, this represents a substantial supply chain attack surface. An open-source assessment tool called GitPhish has since been released to allow security teams to perform authorized assessments and detection validation against the technique.

A pattern that crosses platforms

Across these campaigns, the underlying pattern is the same. Attackers identify a SaaS platform that supports OAuth device flow, adapt the playbook to that platform’s specifics (Salesforce’s /setup/connect consent flow, GitHub’s device verification URL, the legitimate Microsoft device login page), and execute the same fundamental attack. As more platforms add support for device flow, the attack surface expands. The campaigns observed to date are unlikely to be the last.

Platforms subject to this attack class

Device code phishing applies anywhere OAuth 2.0 device flow is implemented. The major SaaS platforms that support OAuth device flow and are therefore subject to this attack class include:

• Microsoft 365 and Entra ID
• Google Cloud
• GitHub
• GitLab 
• Okta
• Auth0
• OneLogin
• Ping Identity
• Zoom

Each implementation is subject to the same fundamental attack pattern. An attacker initiates the device flow, delivers the code to a victim through phishing or vishing, and obtains a valid token once the victim completes authentication. The exposure profile varies meaningfully across platforms based on implementation choices.

Identity providers such as Auth0, Okta, OneLogin, and Ping Identity present a particular category of risk worth highlighting. A compromised token at the identity provider can cascade to every downstream application federated through that IdP. A single phished session against the identity layer can produce SSO assertions to dozens of downstream SaaS applications, multiplying the impact significantly compared to a compromise at any single SaaS platform.

Google Workspace is an example of a meaningful technical control worth mentioning. Google has restricted which OAuth scopes are available through device flow. Gmail, Drive, Calendar, and most Workspace APIs cannot be accessed by tokens issued through this mechanism. Google Cloud APIs remain accessible through device flow, but the broader Workspace data set is not. This is a design pattern other vendors could consider adopting.

Even when device flow is not available on a given platform, the broader social engineering pattern remains applicable. After Salesforce removed device flow, the same threat actors that previously ran device code campaigns shifted to standard OAuth authorization code grants with similar effect. The attack vector survives the specific countermeasure, which means defensive strategy must focus on the consent layer rather than on individual grant types.

How to defend against device code phishing

Device code phishing succeeds because it abuses legitimate authentication workflows rather than exploiting credentials directly. As a result, effective defenses focus on OAuth visibility, consent governance, identity monitoring, and token management rather than traditional phishing controls alone.

Maintain a complete inventory of OAuth grants and connected applications

Security teams should maintain continuous visibility into authorized OAuth applications, granted permissions, and user consent activity across their SaaS environment. Every connected application should be evaluated based on its requested scopes, publisher reputation, and business justification.

Because device code phishing ultimately results in a user authorizing an application, visibility into OAuth grants is one of the most effective ways to identify consent-based attacks regardless of the specific OAuth flow used.

Restrict unnecessary OAuth authorization paths

Where supported, organizations should disable OAuth device flow if it is not required for business operations. Security teams should also restrict user consent to verified publishers, require administrative approval for high-risk permissions, and regularly review existing OAuth authorizations.

These controls reduce the opportunities attackers have to obtain long-lived access through social engineering.

Monitor for identity-layer indicators of compromise

Traditional email and network security controls often have limited visibility into device code phishing activity because victims interact with legitimate vendor infrastructure throughout the attack.

Detection efforts should focus on identity-layer telemetry, including unusual OAuth grants, abnormal token usage, suspicious sign-in activity, new device registrations, and unexpected application authorizations.

Continuously monitor for malicious OAuth applications and infrastructure

Many phishing-as-a-service operations reuse client IDs, redirect domains, and supporting infrastructure across campaigns. Monitoring OAuth activity against known indicators of compromise can help security teams identify malicious applications before they are used for large-scale data access or persistence.

Focus on consent security, not just device flow

Device code phishing is only one way attackers abuse OAuth authorization. Even when vendors restrict device authorization flows, threat actors can often achieve similar outcomes through other OAuth grant types.

Long-term defensive strategies should focus on securing the consent and authorization layer across SaaS applications rather than treating individual OAuth flows as isolated risks.

How AppOmni helps secure against device code phishing

AppOmni helps organizations operationalize these defenses across their SaaS environment by providing visibility into OAuth activity, identity risks, connected applications, and threat indicators.

• Continuous OAuth and connected application inventory: Gain visibility into OAuth grants, application permissions, user consent activity, and connected SaaS applications across supported platforms.
• Posture management against insecure configurations: Identify configuration gaps that increase exposure to consent-based attacks, including risky OAuth settings, consent controls, and authentication policies.
• Threat detection at the identity layer: Detect suspicious authorization events, anomalous token activity, and identity behaviors associated with OAuth abuse and token-based attacks.
• Indicators of compromise for known phishing infrastructure: Identify known malicious OAuth applications, client IDs, redirect domains, and related infrastructure associated with active phishing campaigns.

In summary

A few patterns are worth internalizing as defenders model this threat:

• Phishing continues to evolve. The shift from credential theft to OAuth token theft is part of a longer pattern in which attackers move up the authentication stack as defenders strengthen each lower layer. Device code phishing is the current expression of that shift; it will not be the last.
• MFA does not prevent this attack. The victim completes MFA themselves on the real identity provider. Phishing-resistant MFA reduces the attack window but does not eliminate it. The most effective control is blocking OAuth device flow where it is not required.
• The attack is invisible at the network and email layers. There is no fake page, no malicious domain, and no proxy. URL reputation, email security gateways, and AitM detection cannot identify this attack pattern. Detection must occur at the identity layer.
• Refresh tokens survive credential rotation. Default token lifetimes are weeks to months. Password resets do not revoke them. Compromised accounts remain compromised long after standard incident response steps are complete.
• Connected OAuth application inventory is essential. Even when device flow is allowed, the attack still requires the victim to authorize an application. Continuous monitoring of OAuth grants, new authorizations, high-risk scopes, and unverified publishers catches the attack pattern as it executes.
• The vector survives specific countermeasures. Vendors can close device flow as Salesforce did, but the same threat actors simply shift to other OAuth grant types. The strategic answer is visibility at the consent layer, not focusing on individual grant types.

Device code phishing is the latest example of attackers shifting from credential theft to token theft, exploiting legitimate OAuth workflows that many organizations were never designed to monitor. As SaaS ecosystems become more interconnected, security teams need visibility into OAuth activity, connected applications, and identity-layer behavior to reduce risk and respond before a compromised token becomes a larger security incident.