In February 2025, Russian threat actor Storm-2372 used Microsoft Teams meeting invite lures to deliver device code phishing messages, stealing victims’ authenticated sessions. In March 2026, we saw a surge in device code phishing attacks stemming from the EvilTokens phishing-as-a-service (PhaaS) kit. And more recently, other popular PhaaS platforms like Kali365 are building device code phishing into their cybercrime product offerings.
Device code phishing is nothing new – in fact, the concept has been around for six years, and the processes it abuses (OAuth and Device Code Authorization) have been around for far longer.
But as these campaigns show, device code phishing is havinga bit of a moment right now.
In the June 2026 episode of Tradecraft Tuesday, Huntress Principal Product Researchers Jenko Hwong and Dave Kleinatland pulled back the curtain on what this attack entails, why it’s becoming more prevalent, and why it poses particularly problematic challenges for defenders.
What is device code phishing? Exposing its ‘dirty underbelly’
A quick primer on OAuth and device code authorization
Before understanding device code phishing, we need to first understand how the legitimate process of device code authorization works.
It all started 14 years ago with OAuth 2.0, an authorization framework that lets an app access resources on a user's behalf without ever touching their password. Instead of sharing credentials, the user grants permission and the app receives a scoped access token.
OAuth solved the "password sharing" problem. Before it existed, letting one app reach a user’s data on another service meant handing over their actual username and password. That opened all kinds of security woes: apps could see user passwords and do anything their accounts allowed, and they couldn't revoke access without a password reset that broke everything else.
OAuth replaced this with delegated, limited access: apps get only the permissions granted, for a limited time, revocable anytime without touching passwords or other connected apps.
Then in 2019, an OAuth 2.0 extension called device authorization grant arrived. This process is meant for devices with limited input or no browser like smart TVs or consoles, and it works by displaying a short code and URL on these types of devices. The user authorizes on a separate device like their phone, decoupling login from the constrained device.
This is all leading up to 2020, when Dr. Nestori Syynimaa (an Azure AD/M365 expert and creator of the AADInternals toolkit) introduced a phishing technique abusing this very flow. And here our device code phishing story begins.
The attack itself
At a high level, device code phishing abuses these legitimate Microsoft authentication flows. Normally, a user goes to microsoft.com/devicelogin, types in a short 8-character code, and authorizes their device. Attackers turn this against users by generating the device codes themselves and then using phishing lures to trick people into entering those attacker-controlled codes.
Once the victim submits the code and approves the prompt, the attacker's backend instantly receives valid OAuth tokens.
This is concerning for a number of reasons. Part of the reason that device code phishing is so insidious is that threat actors are attaching themselves to this legitimate authentication flow. All those phishing red flags that employees have been trained to look out for (like sketchy websites) no longer apply. The other challenging part of this attack is that by stealing tokens, threat actors are able to get around security measures that organizations are increasingly adopting, like multi-factor authentication (MFA).
Device code phishing in the wild
We’ve seen device code phishing play out in several incidents.
One campaign came from Storm-2372, a suspected Russian nation-state threat actor active since August 2024, has targeted governments, NGOs, defense, telecom, healthcare, and energy organizations across Europe, North America, Africa, and the Middle East. In February 2025, the group used device code phishing to steal OAuth tokens, first building rapport with targets via WhatsApp, Signal, or Teams while impersonating prominent individuals, then luring them into entering attacker-generated device codes on the legitimate login pages.
In another incident starting March 2, 2026, Huntress detected a large-scale device code phishing campaign targeting 344 organizations across the US, Canada, Australia, New Zealand, and Germany. Threat actors abused Railway.com, a developer PaaS platform, as a token-harvesting engine, exploiting its clean IP reputation to bypass Microsoft's risk scoring. Phishing lures were highly personalized (construction RFPs, DocuSign, voicemail notifications) and routed through multi-hop redirect chains including compromised websites, security vendor URL rewriters, and Cloudflare Workers pages.
The campaign was later attributed to the EvilTokens PhaaS platform. In fact, we’ve seen several PhaaS platforms that have now built device code phishing into their service offerings for cybercriminals, including Kali365. This has led to the further proliferation of this type of attack vector.
“Hope-as-a-service”
Threat actors get to control PhaaS, so we at Huntress are claiming rights to a mitigations-related term we call “hope-as-a-service.” ;)
We can’t talk about device code phishing mitigations without mentioning Conditional Access, a Microsoft Entra ID security feature that enforces access policies based on signals like user, location, device, and risk level. Conditional Access policies evaluate each sign-in attempt and apply controls to balance security with usability when accessing applications and resources.
A Microsoft-managed Conditional Access policy that blocks device code flow was actually released in 2025 – although one important caveat is that blocking device code flow via Conditional Access can interfere with the Device Registration Service (DRS), so users should plan for that exception carefully.
Surprisingly, at Huntress we’ve seen around 25% of people that have paid for Conditional Access but haven't set it up yet, allowing threat actors to potentially slip between the cracks. Users of Conditional Access policies should make sure that they see the policy through.
Other mitigations for this type of attack include:
-
Monitor New Device Registrations: Users who aren’t monitoring new devices added to their Entra environment should start now. When a device is registered (even by a remote attacker), an event is logged and the device artifact appears in the Entra devices section. Some attackers are lazy and don't change default machine names, which makes detection easier.
-
Watch for Suspicious Token Exchange in Logs: The logs contain actionable signals, like app names, back-end resources, session IDs, unique token identifiers, and PRT identifiers. One key red flag is when Office app tokens are used against Azure Resource Manager.
-
Disable Device Code Flow Where Possible: Disabling device code flow outright is an option, though it needs to be weighed against operational needs. Device writeback being disabled in Entra can also help prevent the device registration abuse piece specifically.
Like what you just read? Join us every month for Tradecraft Tuesday, our live webinar where we expose hacker techniques and talk nerdy with live demos. Snag your spot now!
