Device code phishing attacks have skyrocketed: here’s what you need to know

The OAuth 2.0 device authorization grant was designed to enable input-constrained devices to sign-in to apps by asking the user to complete the login on a separate device by entering a code. But today, it’s mainly used when accessing CLI tools, meaning that many users encounter the device code flow daily. 

Device code phishing attacks designed to exploit this authorization flow are not new — it was among the first techniques that we added to the SaaS attacks matrix back in 2023. But it’s taken until now for it to really enter mainstream adoption. 

The technique tricks a user into issuing access tokens for an attacker-controlled application (not a device, confusingly). Any app that supports device code logins can be a target. Popular examples include Microsoft, Google, Salesforce, GitHub, and AWS. That said, Microsoft is, as always, much more heavily targeted at scale now than any other app.

We’ve always been surprised that attackers haven’t commonly used device code phishing in their standard toolkit, preferring session-stealing AITM phishing and other social engineering attacks like ClickFix. But it’s pretty clear from the recent data that the shift to mainstream adoption has now happened. 

In this blog post, we’ll explore the history of device code phishing, what’s changed for it to enter mainstream adoption, how it works under the hood (with recent examples), and what security teams can do about it. 

A brief history of device code phishing

The technique was first documented in 2020, before Secureworks released the first tooling framework PhishInSuits a year later. A host of research followed, including SquarePhish v1 (using QR codes to trigger the 15 minute code expiration window), Dirk-Jan Mollema’s key research (chaining device code phishing via Microsoft apps into Primary Refresh Token (PRT) acquisition to gain full browser-level access) and Dennis Kniep’s DeviceCodePhishing tool which automates the entire flow with a headless browser. (Other recent noteworthy tools include SquarePhish2 and GitPhish, so shout out to those too). 

It wasn’t until August 2024 that in-the-wild exploitation was first identified, with Russia-linked campaigns then continuing into 2025 before entering mainstream criminal adoption. This trend has continued to gather momentum in 2026 with EvilTokens, the first reported criminal PhaaS kit for device code phishing, already powering massive campaigns after launching in February. 

Some of the noteworthy in-the-wild campaigns include:

• Storm-2372, tracked by Microsoft and Volexity, linked to multiple Russia-aligned clusters, combining spear-phishing and social engineering with device code phishing payloads against strategic intelligence targets.

• The massive Salesforce campaign operated by Scattered Lapsus$ Hunters (SLH) combined vishing with a device code phishing payload targeting Salesforce. The attacks morphed into a broader supply chain campaign using stolen credentials, ultimately resulting in 1000+ organizations being compromised and over 1.5 billion stolen records claimed. 

• A massive spike in activity in late 2025 and 2026. This includes multiple threat clusters tracked using device code phishing techniques, more criminal operations linked to SLH, and hundreds of organizations being targeted via PhaaS architecture, which looks to be the same campaign as the recently uncovered EvilTokens PhaaS reported by Huntress (featuring abuse of the Railway PaaS platform). Abnormal has also reported on a closed-source PhaaS kit called Venom that offers device code phishing capabilities that appear visually and functionally similar to EvilTokens.   

What we’re seeing in the wild

As mentioned, we’ve also seen a huge spike in device code phishing activity this year, with multiple kits, page designs, and lure types. We’ve identified 10 distinct kits in circulation in the wild, with EvilTokens being the most prevalent. It’s clear that attackers are both spinning up their own kits and creative derivatives of others — we’ve seen kits that are visually similar to EvilTokens (close enough to be clones or forks) but with very different backends, for example AWS, Digital Ocean, 2cloud, and more. 

“ANTIBOT” (EvilTokens)

Huntress, Sekoia, and researcher Paul Newton have already done a great job of providing IOCs for the recent EvilTokens activity spike, including multiple backend Railway IPs in authentication events. 

Beyond the most widely observed implementation featuring a Cloudflare Workers frontend and Railway backend for authentication, we’ve also tracked additional versions of EvilTokens in circulation since January 2026 (many of which remain live along with the current “production” version of the kit). 

You can see an evolution of the kit in the videos and screenshots below, from early precursors seen in mid-January, the first mentions of ANTIBOT in the page code in late-January, the parallel development of a “Courts Access” fork that lacks the ANTIBOT references, and finally production EvilTokens in February. One of the key threads between the versions is the presence of a generateFallbackCode() JS function and use of a /generate-codes API call. 

Early implementations were quite different, for example using ScrapingBee to generate the displayed code, and varied hosting on vercel, fastly, edgeone, and others. 

After initially appearing on custom domains, the production version is now predominantly hosted on Cloudflare Workers, as per the broader tracking of the campaign. The descriptive HTML comments around ANTIBOT functions have also been removed in later versions. 

The production version of EvilTokens showcases common detection evasion techniques we've come to associate with PhaaS kits in the AiTM space — using multiple redirects through trusted sites before serving the malicious page, using bot protection to block security tools from analysing the page, and so on. It also uses a pop-up window for the device code entry rather than a redirect, reducing the friction for the victim (it looks pretty convincing, too).

“SHAREFILE”

“CLURE”

“LINKID”

“AUTHOV”

“DOCUPOLL”

“FLOW_TOKEN”

“PAPRIKA”

“DCSTATUS”

“DOLCE”

Device code phishing under the hood

The attacker POSTs to the authorization server's device authorization endpoint with its client_id (i.e. an application ID) and requested scopes or resources. The server responds with a device_code (used for polling), a user_code, a verification_uri, an expires_in value, and a polling interval. The user visits the URL, enters the code and approves the request. Meanwhile, the device polls the token endpoint. Once approved, the server returns an access token, a refresh token (if offline_access was requested), and an ID token (if openid was included). The attacker now has API access to the victim's account. 

Broadly, this gives the attacker a comparable level of control to a “normal” phishing attack (with conditions based on the scopes granted and specific app being targeted) while API access grants additional capabilities beyond standard browser sessions. When combined with other techniques, this access can be exchanged to open normal browser app sessions and access SSO connected apps (e.g. the PRT escalation technique for Microsoft that I mentioned in earlier research).

At this point, you can achieve a number of objectives both inside the app ecosystem and across SSO connected apps — e.g. data theft, disruption, and ultimately extortion.

Critically, the initial request to generate a device code is typically unauthenticated across all providers — anyone can generate one, from any machine, without proving any relationship to the target organization.

So, the attacker has to deliver a set of instructions via a phishing channel (e.g. email, social media DM, corp IM platform, and so on) with a device code that they have generated. The victim then enters this code on the legitimate device code login page for that app and issues the tokens to the attacker.

First-party vs. third-party apps

First-party applications are commonly abused in Microsoft-targeted attacks. These are real Microsoft applications registered in every Entra ID tenant. Not only are they allowed by default (unlike third-party apps that are often subject to additional restrictions and require additional tenant-level consent before they can be accessed by a user), they come with pre-consented permissions, and can even access undocumented “legacy” scopes. 

Many Microsoft first-party apps also belong to the Family of Client IDs (FOCI), meaning a refresh token obtained for one family member can be exchanged for access tokens to other family members without re-authentication. This means that an attacker can silently pivot to other apps and APIs from a single phished session.

In other cases third-party applications are leveraged. This doesn’t mean these are fresh, attacker created apps however (though it’s easier than ever for attackers to spin up their own OAuth apps using AI tools). They can simply be attacker-controlled instances of otherwise legitimate apps.

Why device code phishing is so dangerous

Device code phishing bypasses authentication controls (including passkeys)

A device code phishing attack cannot be prevented with authentication controls. This includes all forms of MFA and even “phishing-resistant” authentication methods such as passkeys. 

The device code authorization is effectively performed post-authentication. If you already have an active session in your browser, entering the device code and selecting your account from a drop-down menu is all that's needed. No password or MFA required. You can see an example in the video below.

Even if you do have to sign in again (because you're not already signed in for some reason), the attack still works because it isn't targeting the login — it's targeting the authorization layer instead.

This is what makes device code phishing different to other standard phishing methods like AiTM phishing (and arguably even more effective in environments with strict identity control enforcement). 

Device code logins are a feature, not a vulnerability, making attacks difficult to block

Device code authorization is a legitimate mechanism that is regularly used in an enterprise environment, particularly for CLI logins. This is a problem for security teams because the phishing attack effectively happens on the legitimate site. The code is delivered to the victim via message or webpage, but the attack itself only happens when that code is entered onto the real device code login page.

Since there’s no traditional phishing payload being delivered on the attacker’s webpage, these sites are more resistant to detection and less likely to be flagged by email and network analysis. And in many cases, there’s no email (or webpage) to analyze at all.

Various apps can be a target, all of which implement the device code flow in slightly different ways, and also offer different levels of control and default security around these logins. For example, Google Workspace is a significantly lower risk target than Microsoft, GitHub, or AWS because Google explicitly limits which scopes are available to the device code flow. 

Security recommendations

Security teams need to consider the risk posed by device code phishing across multiple apps where device code authorization grants are common, particularly for developers and technical users.

In an ideal world, you would simply block device code logins. But this can’t be done without causing serious disruption in some environments, while some apps simply don’t provide the tools required to do so. For example, device code is the default CLI sign-in method for GitHub. Developer-heavy organizations are likely to encounter higher levels of legitimate use.

Microsoft arguably offers the strongest control options (other than Google, who negate it right out of the gate), though they do require a fair amount of work. Microsoft now explicitly recommends blocking device code flow for tenants that haven't used it in the past 25 days. Their guidance is to create a custom CA policy: target relevant users, set the Authentication Flows condition to block Device Code Flow, and set the grant control to Block Access. Deploy in report-only mode first to identify any legitimate device code usage. 

For other apps, you’re mainly limited to monitoring and response. Ensuring you’re getting authentication logs for these apps is vital, and searching for unusual access patterns (e.g. unusual login protocols, having different IPs for the authorization grant and subsequent account activity).

How Push Security can help

Push customers can use our browser-based capabilities to overcome the limitations of app-level controls and detect, intercept, and shut down attacks in real time. 

Our research team is already tracking multiple device code phishing campaigns and toolkits, including the EvilTokens kit. Blocking controls are already in place to prevent customers from interacting with malicious pages that match our detections for these new toolkits, ensuring that these pages can be identified and blocked in real time regardless of the infrastructure. 

Using Push you can also configure in-browser warnings whenever a user accesses a URL used for device code logins. This provides universal, last-mile protection against even ‘zero-day’ device code phishing attacks using previously unidentified toolkits.  

When a user visits those URLs, Push will also emit a webhook event that the banner was shown and acknowledged. If a user opts to proceed, you can treat this as a high-fidelity alert for your security team to investigate, providing app-agnostic telemetry that may not already be provided in your logs from that particular vendor. You can also simply use Push to block users from accessing device login pages if you’re confident that disruption won’t be caused. 

Learn more about Push

Push Security's browser-based security platform detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking. You don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.