Device code phishing – the abuse of the OAuth 2.0 device authorization grant to steal access tokens – has evolved from a niche red-team technique to an industrial-scale threat in under six months.
Designed for input-constrained devices like smart TVs, printers, and so on, the device authorization login flow has been adopted by a wide range of apps and use-cases that it wasn’t originally intended for – most commonly CLI logins.
Researchers first described the attack vector in 2020, but it took until 2024 before nation-state actors like Storm-2372 started using it in the wild. By 2025, ShinyHunters was using device code phishing against Salesforce tenants at scale, then in February 2026, the EvilTokens kit arrived and criminal adoption skyrocketed. By April, Microsoft was reporting 10 to 15 entirely new campaigns every 24 hours. Barracuda counted 7 million attacks in four weeks. The FBI issued a standalone advisory on Kali365, the first US federal agency PSA about a specific phishing-as-a-service kit.
Push Security added device code phishing to its Browser & Identity Attacks Matrix back in 2023 and now tracks more than 25 distinct device code phishing kits in the wild and counting. Entering the second half of 2026, there’s no sign of the pace slowing.
Push recently ran a deep-dive webinar on device code phishing covering the attack mechanics, a live demonstration of a custom-built phishing kit, and what comes next. Here are six takeaways that security teams should have on their radar.
1. It defeats every form of MFA, including passkeys
Device code phishing doesn’t attack the login flow. It attacks what happens after login – the authorization layer. In most cases, the victim is already signed into their Microsoft account when they encounter the phishing page. They copy a short code, enter it on the legitimate Microsoft device login page, pick their account from a dropdown, and click allow. That’s the entire attack.
Passkeys, hardware security keys, enforced phishing-resistant MFA – none of it makes a difference, because the device code flow is separate from the authentication mechanism. The attack exploits the fact that proving your identity and granting access to an application are two different things, and most security controls only protect the first.
2. The PhaaS ecosystem has fully industrialized it
Device code phishing is no longer a specialist technique. It’s a standard feature in the phishing-as-a-service catalog. Tycoon2FA, which Push previously tracked as the most common AiTM phishing kit in the wild, added device code phishing to its framework in May. Kali365 offers both AiTM and device code phishing in a single platform.
Some security firms are reporting that the structural similarities between kits are evidence of the ecosystem forking and fragmenting. But based on what we’ve seen, kits built independently using similar LLM instructions can look just as alike (more on this below).
Regardless, the capabilities these kits offer keep getting better: for example, ARToken ships with PRT persistence, mailbox access, BEC automation, and SharePoint exfiltration packaged as product features for paying operators.
The commercialization pattern mirrors what happened with AiTM phishing: a technique moves from a research curiosity to nation-state espionage to a criminal commodity, each stage accelerating faster than the last. But device code phishing completed that entire journey in a matter of months – a compression that reflects both the maturity of the existing PhaaS market and the speed at which AI-assisted development lets new capabilities get built and distributed.
3. Attackers are vibe-coding new kits faster than defenders can catalog them
Push now tracks more than 25 distinct device code phishing kits in the wild – a number that would have been inconceivable before this year. For context, a brand-new AiTM phishing kit appearing in the wild used to be a significant event that happened once every few months. Having 25+ kit families emerge this year alone reflects a fundamental change in how phishing tools get built.
AI-assisted development has collapsed the barrier to entry. Many of the kits Push tracks share structural similarities like similar layout patterns and similar code architecture, because they were generated by LLMs responding to similar prompts. Push VP R&D Luke Jennings spun up his own kit to demonstrate just how easy it is.
4. It’s not just a Microsoft problem
99% of the device code phishing Push detects today targets Microsoft, but the webinar demonstrates why that won’t last. The OAuth 2.0 device authorization grant is a cross-platform standard, and any application that implements it is a potential target.
Nation-state actors have already used device code phishing against Salesforce in targeted campaigns. The ShinyHunters Salesforce campaign, which compromised over 1,000 organizations and produced 1.5 billion stolen records, used a malicious “DataLoader” application to abuse the device code flow at scale.
Device code phishing is less universally applicable than AiTM – not every app implements the device authorization grant – but it has the advantages we’ve already described: it bypasses all MFA including passkeys, it doesn’t require cloning a login page, and the user interacts with legitimate provider URLs.
Apps like GitHub, AWS, and others all support device code flows, and for GitHub it’s a core part of how developers authenticate CLI tools and VS Code tunnels. As kit developers look beyond Microsoft, these are the targets that open up.
5. It’s part of a broader shift toward authorization attacks
Device code phishing isn’t an isolated technique. Attackers are moving away from the authentication layer because that’s where defenders have concentrated their controls, and authorization mechanisms have received comparatively little attention.
Push uncovered ConsentFix in late 2025, a browser-native OAuth consent phishing technique initially attributed to Russian actors that has since appeared in criminal toolkits. Like device code phishing, ConsentFix targets the authorization layer and defeats passkeys for the same structural reason: the attack occurs after authentication has already succeeded.
As attackers continue to develop new ways to abuse consent flows, device registration, and token exchange mechanisms, this gap will widen unless defenders adapt.
6. Detection has to happen where the attack happens
Device code phishing pages can be delivered through any channel: email, messaging apps, social media, search engine results, compromised websites, and more. The user enters the code on the provider’s legitimate login URL, which means the attack transits through infrastructure that no network proxy, URL reputation service, or email gateway is going to block.
The most common mitigation advice for Microsoft environments is to restrict device code authentication flows via conditional access policies, and that’s a good step where it’s feasible. But it’s not always straightforward – device code flows exist for legitimate reasons, and larger organizations often find they can’t simply disable them without breaking developer tooling, CLI workflows, or constrained-device scenarios.
Even where organizations do lock it down for Microsoft, that does nothing to protect against device code phishing targeting GitHub, AWS, or other platforms where equivalent conditional access controls may not exist.
The only vantage point that sees both the phishing lure and the device code approval – across any provider – is the browser, which is where Push operates. Push’s agentic threat hunting pipeline writes and deploys detection rules continuously, targeting the technique class: i.e. the behavioral signatures of device code phishing kits and the device code approval flow itself rather than specific kit fingerprints or domains. That distinction matters when new kits are appearing weekly and burning through infrastructure faster than any IOC-based approach can track.
For the full technical breakdown, including a side-by-side demonstration of what the victim sees and what the attacker sees during a device code phishing attack, the privilege escalation chain from stolen tokens to full SSO-level access, and the defensive options available, watch the webinar.
Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser – high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.
Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can’t see.
Book a live demo to learn more.
