OAuth My Word: How Device Code Phishing Learned to Knock Politely

Executive Summary

In the past 5 months, security vendors at large have noticed an extreme uptick in a specific type of email campaign called device code phishing. This proliferation was made possible by malicious turnkey applications with reasonably low technical and financial barriers to entry.  The deeper reason for their sustained growth is a defense-resistant infrastructure that presents legit links to the victim.  The scale and speed are largely enabled by AI / LLM, with reports citing over 1000% increase in the attack vector. In this blog, we’re going to break down the attack, the adversary’s use of AI/LLM, and what we’re doing to detect these attacks.  

Device Code Phishing

You’re probably familiar with traditional phishing campaigns, but if not: user clicks a link from their email, lands on a spoofed Microsoft (or other cloud service) login page, which collects Username:Password (credential) combinations.  This later evolved into collecting multifactor authentication (MFA) tokens as well.  As defenders, we taught users to look at the URL they were about to click on or in the URL bar before they entered credentials, and defenses got tight enough to prevent the majority of these campaigns. 

Then adversary-in-the-middle (AiTM) came about. It’s the same principle from the victim’s perspective, but the attacker collected a session cookie rather than just credential combos for more advanced persistence and follow-on activity.  

The new kid on the block: device code phishing.  The goal of a device code phishing attack is to trick a user into authorizing access to their account through a device code prompt, providing an attacker with a valid account OAuth token. On their end, an attacker will generate a legitimate user code via a cloud provider like Microsoft Entra ID and send it to the victim.  The victim receives a phishing email with a convincing lure to click a link. The link points to the official device pairing endpoint for the cloud platform (mostly but not limited to Microsoft – the focus of this post). Once the victim navigates to the URL and enters their authorization code, they unknowingly authorize the attacker’s rogue application to access their account. 

The crux of the recent onslaught of attacks is that end users have nothing but their intuition to tell them something’s wrong.  Traditional methods of identifying phishing emails (simply matching the URL to the activity) fail – because attackers are abusing legitimate services, the link a victim receives (and many times the hops to reach authorization) ultimately leads to an actual Microsoft authorization endpoint.  At that point, only detailed knowledge about device code authorizations may be concerning for the end user.  

Over the past 6 months, CyberMaxx (and others) have noted a dramatic rise in these phishing attacks as well as the expansion and maturation of their ecosystems becoming increasingly enabled and reliant on AI and LLM resources.  

EvilTokens & Beyond

One platform that has made attackers’ lives very easy and has made waves recently is EvilTokens. But it’s important not to lose the forest for the trees because it’s not the only game in town.   

EvilTokens is a phishing as a service (Phaas) platform which is easily attainable to anyone with access to Telegram, roughly $2,000, and a target list.  As with all of the platforms we’ll speak about, it’s designed as a business email compromise (BEC) tool. It allows for much more once a foothold is established because it incorporates AI/LLM automation directly.  

Another platform capable of this attack is “Kali365”.  Of note, this platform has more aliases than most: Clure, Octopi365, and Freedom365. This may signify internal differences or splintering of the original authors, or it may just be attacker “shenanigans”.  It’s also distributed through Telegram.  The most notable feature is pairing device code phishing with adversary-in-the-middle (AiTM) infrastructure for fallback on cookie & session theft. AiTM may also allow for a downgrade attack which bypasses MFA.   

A platform we’ve watched mature quickly is Tycoon2FA. This was one of the first AiTM kits available and landed victims on a custom page to collect their creds and attempt MFA bypass. It was eventually taken down (March 2026) in a joint disruption operation by Europol and others but popped right back up and resumed full operations within 14 days.   

Ultimately, the importance of intelligence dissemination on adversaries and the landscape is knowing how to defend. But the sheer volume and proliferation of these platforms is worth noting – there are over 14 unique kits being publicly reported on, each with its own nuance.  

The Attack, the Infrastructure

As we mentioned earlier, in this attack the victim receives a code for authorizing an application to connect to their account. How does that happen?  It’s not a bug; it’s a feature! The feature exists to connect “constrained devices” (like your TV) to your account. When you initiate a connection, you’re provided with a device code which grants the app access. 

The problem: anyone can request access to your account, on your behalf.  

That’s what the attackers do to initiate this process. Then they forward the illegitimate request for access through legitimate infrastructure with a convincing lure, hoping the victim will click their link and grant authorization.  Once approved, the requesting party (attacker) is given the OAuth token to the victim’s account. 

As it happens, device code authorization is also how many developers can connect applications through the command line or limited GUI. Couple that with forwarding to a legitimate page from Microsoft through legitimate web resource, and the attack pattern is now “resistant” to traditional prevention mechanisms.   

To the victim, this looks like they’re authorizing whatever lure the attacker provided, not providing an attacker with unauthorized access.  

This is where we find commonality between attacker tool kits.  The lures here are all very convincing and don’t overtly show signs of attacker infrastructure.  Docusign pages, external payment reminders, construction plans/invoices, and Microsoft Forms or SharePoint pages are the most popular lures. To the victim, they’re just gaining access to the document/item in the lure.  

Where the attacks created on each platform diverge is their infrastructure. EvilTokens was mainly abusing Railway.com for the first half of 2026.  This is a developer Platform as a service (PaaS) which supports harvesting tokens. Its IP was a clean source and bypassed typical email gateway filters. When this slowed, the EvilTokens platform took a queue from Tycoon2FA and pivoted to bitlaunch.io. 

For delivery, EvilTokens uses AI-generated lures (mentioned above) and abuses multiple “hops” (redirects) like Cloudflare workers, AWS, and vercel.app. Commonality here: successfully capturing a token means sometime in the first 60-90 minutes regenerating it with 90-day validity.  

Kali365 delivery uses Cloudflare infrastructure to bypass email filters while Tycoon2FA couples Cloudflare with github.io.    

Once access is granted and persistence gained, attackers use LLMs to script collection of emails, calendars, and contacts. The attacker uses collection in two main ways: harvest data and expand their target list. 

Once collection is completed (which generally happens quickly), the threat actor relies on LLMs to create new campaigns with their toolkits at scale & speed. In a recent webcast, Huntress suggested that if an attacker using EvilTokens had access to a victim’s voice, pivot lures could be created using the victim’s voice to make pivot campaigns.  

It’s important to recognize the role of AI in the swarm of campaigns we’re seeing.  Right now, marketing battles from AI companies as well as many trusted sources of information have us embroiled in obscure minutiae of theoretical automatic attack chains which include 0-days, N-days, and their exploitation. But we all need to focus on what’s at hand: the nightmare your security teams have been fearing is already here, being delivered to your environment’s inboxes through AI with no malware, no attachments, and all the AI attackers can manage to deploy.  

What is CyberMaxx Doing for Detection?

This is a hard challenge to solve, and CyberMaxx continues to evolve our approach as attacker behavior shifts. Detection here isn’t about firing a single alert — it’s about building and tuning custom alerting rules alongside “AI”-driven correlation and decision engines that piece together telemetry from multiple sources into a contextual picture of each event, rather than relying on any one indicator in isolation.  

Identity and access context:  

• Whether the user has authenticated from this device before, and whether the device is consistent with what’s expected for that user’s role or OU?
• Data embedded in the collected logs — does the user-agent match the device, and does it carry hallmarks of Linux agents seen in prior campaigns? (We generally recommend restricting to approved applications only.) 
• We’ve noticed a lot of campaigns deploy configuration changes in the account. This is a strong agnostic indicator of account compromise on its own.

Patterns in device code “flow”: 

• Does the device code flow have an abnormality? Consistent / semi-consistent automated token refreshes may stand out for your users.
• Does the token geography line up with the users?
• Does the token have a LOT of activity then: a) go dormant for days or b) have scheduled periods with more activity?
• Multiple registrations in a short period of time? 

By correlating and pulling context from telemetry, CyberMaxx moves beyond single-point alerting to build a contextual custom detections for device code flow abuse.  

Prevention

Prevention against this type of attack is somewhat straightforward but will depend on administrative support for the solutions. 

• Conditional Access can enforce these contextual constraints and restrict device code flow to specific approved scenarios.
• STRONGLY consider using only approved applications for device code approval. 

Conclusion

Attackers are chaining AI workflows that abuse legitimate application features to gain a foothold at speed & scale.  Defenders need to supplement traditional alerting by asking themselves if the context of the events observed in device code attacks makes sense. To do so, they need to gain additional information and tooling to bring that context to light. CyberMaxx is increasing its capabilities by using detection strategies coupled with AI workflows to make these decisions at speed and scale. 

References

1. Internal events
2. https://www.levelblue.com/blogs/spiderlabs-blog/the-device-code-phishing-tsunami-what-were-seeing-in-the-wild
3. https://spycloud.com/blog/kali365-anatomy-of-a-microsoft365-phishing-as-a-service-kit/
4. https://www.ic3.gov/PSA/2026/PSA260521
5. https://www.huntress.com/blog/tradecraft-tuesday-device-code-phishing-explained