The OAuth 2.0 device authorization grant was originally designed to solve a usability problem: how do you authenticate on devices with limited input capabilities? Think smart TVs or CLI tools. Instead of typing complex credentials, users enter a short code on another device to complete authentication.
What was built for convenience has now become a powerful attack vector.
Device code phishing is no longer a niche technique buried in research papers. It has rapidly evolved into a mainstream attack method, with threat actors operationalizing it at scale through phishing-as-a-service (PhaaS) kits. In 2026, we are witnessing a sharp inflection point where this method is being actively weaponized across industries.
Recent telemetry shows a dramatic rise in activity, with phishing pages leveraging device code flows increasing by up to 37.5 times. This is not an incremental shift—it’s a full-scale adoption.
Device code phishing first appeared in research circles around 2020. Early tooling like PhishInSuits and later innovations such as SquarePhish and DeviceCodePhishing laid the groundwork. These tools demonstrated how attackers could trick users into authorizing malicious applications without ever stealing passwords.
However, real-world adoption lagged behind.
That changed in 2024 when state-linked threat actors began using the technique in targeted campaigns. By 2025, cybercriminal groups followed suit. Now in 2026, the emergence of kits like EvilTokens has made device code phishing scalable, accessible, and dangerously effective.
PhaaS has played a critical role here. Just as it accelerated adversary-in-the-middle (AiTM) phishing, it is now lowering the barrier to entry for OAuth abuse.
What We’re Seeing in the Wild
Security researchers have identified at least ten distinct phishing kits actively exploiting device code flows. Among them, EvilTokens stands out as the most dominant.
These kits are not static—they evolve rapidly. Variants differ in infrastructure, backend logic, and evasion techniques, but they share a common goal: trick users into granting access tokens.
Common Infrastructure Patterns
Frontend Hosting
- workers.dev
- vercel.app
- github.io
- fastly.net
- edgeone.dev
Backend Infrastructure (examples)
- 162.220.232.71 (Railway AS400940)
- 71.11.42.193
- 72.218.25.107
Network Paths
- /api/rate-limit
- /api/fingerprint
- /api/captcha-verify
- /api/init
- /api/generate-code
- /api/check-auth
Lure Themes
- Microsoft 365 (Outlook, Teams, SharePoint)
- DocuSign
- Adobe
- HR documents and salary adjustments
Example Domains
- teams-zpfvwnpxuc[.]edgeone.dev
- authenticate-m365-accountsecurity-m-pi[.]vercel.app
- interface-auth-en-useast[.]global.ssl.fastly.net
- index-z059-document-pending-reviewsign-xlss7994824[.]awalizer[.]workers.dev
These campaigns often use trusted infrastructure and multiple redirects to evade detection. Some even deploy anti-bot systems to block analysis tools, mimicking advanced AiTM kits.
How Device Code Phishing Works
At its core, the attack exploits a legitimate OAuth flow.
An attacker initiates a request to an authorization server using their own application ID. The server responds with:
- a device_code
- a user_code
- a verification URL
The attacker then tricks the victim into visiting the legitimate login page and entering the user_code.
Once the victim approves the request, the attacker receives:
- an access token
- potentially a refresh token
- optionally an ID token
From that moment, the attacker has API-level access to the victim’s account.
Critically, this process does not require credential theft.
Why This Technique Is So Dangerous
What makes device code phishing uniquely powerful is that it bypasses traditional security assumptions.
Authentication controls such as MFA or passkeys do not stop it. The user is not being tricked into logging in—they are being tricked into authorizing access after authentication has already occurred.
This subtle shift—from authentication to authorization—renders many defenses ineffective.
Additionally, the attack occurs on legitimate domains. There is no fake login page to detect, no malicious payload to scan. The phishing component is simply the delivery of instructions and a code.
Modern kits further improve success rates by dynamically generating fresh codes via APIs, eliminating the time constraints that plagued earlier campaigns.
First-Party vs Third-Party Abuse
Attackers often abuse first-party applications, especially in Microsoft environments. These apps are pre-approved, widely trusted, and often include legacy permissions.
Some belong to the Family of Client IDs (FOCI), allowing tokens to be reused across multiple services without re-authentication. This enables silent lateral movement across applications.
Third-party apps are also used, but they may face additional consent barriers—making first-party abuse particularly attractive.
Beyond OAuth: A Broader Privacy Concern
While device code phishing is a major concern, it is part of a larger pattern of ecosystem abuse and surveillance.
For example, LinkedIn has been reported to silently scan users’ devices, collecting data about installed software and browser extensions—without disclosure or consent. This includes tools that reveal sensitive attributes such as political views, religious affiliations, and job-seeking activity.
Because LinkedIn ties this data to real identities, the implications are severe. It enables corporate intelligence gathering, competitive analysis, and potentially targeted enforcement actions against users of third-party tools.
The scale of this data collection—and its lack of transparency—raises serious legal and ethical questions.
Our Perspective on This Shift
The rise of device code phishing represents a fundamental shift in how attackers think about identity.
For years, defenders focused heavily on protecting credentials. We built MFA, passwordless authentication, and phishing-resistant mechanisms like passkeys. But device code phishing sidesteps all of that by targeting user intent instead of credentials.
This is a deeper problem.
When a user willingly authorizes access—even if manipulated—traditional defenses lose visibility and control. Security teams must now rethink their approach, focusing more on behavioral analysis, consent monitoring, and token lifecycle management.
At the same time, the broader ecosystem is becoming more opaque. The LinkedIn example highlights how even trusted platforms may engage in undisclosed data collection. This blurs the line between security, surveillance, and exploitation.
In our view, the industry is entering a phase where authorization abuse and data visibility will define the next generation of threats.
Defending against this requires more than better tools. It requires better transparency, stricter platform accountability, and a shift toward zero-trust principles—not just for access, but for consent itself.
