TL;DR

Device code phishing is an established technique that the security community has been tracking for years.

Over the past two months, mnemonic has observed a significant increase in device code phishing activity, including multiple attempts targeting our customer base at a scale we have not experienced previously. We’ve seen how threat actors can run device code phishing operations on widely used platforms that blend into normal internet traffic, complicate reputation-based blocking, and give defenders fewer obvious infrastructure signals to work from.

With new phishing-as-a-service platforms like EvilTokens, what was once a more manual technique is now being packaged into services that are easier to run at scale and easier for less capable operators to adopt. AI is leveraged both within the platform to enable automation and accelerate operator workflows, and in the development of the platform itself.

Our research shows that EvilTokens is advertised and sold on Telegram as a ready-to-use service, combining delivery and operational features such as Office 365 capture links, B2B and SMTP sending, open redirects on legitimate domains, and customer-style support features.

How device code phishing went from niche to a mature part of the phishing ecosystem

In practice, device code phishing kits package the infrastructure and workflow needed to abuse a legitimate device login flow and steal tokens at scale.

Over the past year, device code phishing has moved from a niche technique into a more mature part of the phishing ecosystem. This includes higher levels of automation, broader actor adoption, more use of trusted cloud infrastructure, and a growing overlap with other social-engineering approaches such as vishing.

mnemonic has observed an increase in successful device code phishing attacks this quarter, with the increase especially noticeable over the last two months.

Device code phishing does not depend on a fake login page in the usual sense. Instead, it abuses a real authentication flow that many users are less familiar with and therefore less likely to question. It illustrates how phishing is evolving from password theft toward identity abuse and session abuse.

How device code phishing actually works

The underlying mechanism is straightforward:

1. The attacker initiates a device authorisation flow and obtains a valid device code.
2. The victim is lured to a phishing page or support-style interaction where that code is presented.
3. The victim is told to complete sign-in on the legitimate Microsoft device login page.
4. Once the victim authenticates, the attacker’s backend receives the resulting tokens.
5. Those tokens can then be used for post-authentication activity across Microsoft 365 and connected services.

Unlike classic AiTM kits that proxy a live login session, EvilTokens centres on getting the victim to complete a legitimate device authorisation flow and then abusing the resulting tokens.

In practice, the trap may impersonate a service such as SharePoint or DocuSign and present the victim with a verification code alongside a prompt to continue to Microsoft. The victim is then taken to a legitimate Microsoft device authentication page, where they are instructed to copy the displayed code, continue, paste it, and sign in.

The victim is still interacting with a real Microsoft domain. That weakens some of the checks users would normally rely on, such as scrutinising the URL or treating an MFA prompt as a warning sign. If the attacker obtains access and refresh tokens, the result is not just an exposed password but a trusted session that can support follow-on access and persistence.

For a more detailed technical deep dive, see Sekoia’s recent breakdown.

What are EvilTokens?

EvilTokens is the latest shift in device code phishing. What was once a more manual technique is now being packaged into services that are easier to run and easier to scale. Recent campaigns have also shown how trusted infrastructure such as Railway.app and Cloudflare Workers can be used to support the workflow and reduce the effectiveness of reputation-based blocking.

These phishing kits lower the barrier to entry by packaging infrastructure, delivery, and operator convenience into services that more threat actors can use.

EvilTokens is an example of a phishing-as-a-service platform built around abuse of the Microsoft 365 OAuth device code flow rather than primarily relying on adversary-in-the-middle infrastructure. It is a managed criminal service with multiple productised components around the core phishing flow.

Its Telegram presence has a marketplace-style presentation with operator-facing features such as digital products, sender services, link purchasing, balance top-up, withdrawals, order history, and referral functions, reinforcing the impression of a commercialised service built for repeat use.

Those components include:

• an Office 365 capture-link capability tied to device code phishing
• delivery tooling such as a B2B sender and SMTP sender
• a library of open redirects on legitimate domains
• customer-style support and platform-management features

Together, those components show a ready-to-use workflow for token theft, campaign delivery, and post-authentication access.

The platform is also designed to help operators prioritise what to do after access is obtained. Features such as AI Analysis and Keyword Scanner suggest support for reviewing compromised mailbox content, with likely emphasis on finance-related material and other high-value conversations. That points to a service built not just for initial access, but for faster post-compromise triage and more efficient targeting once tokens have been captured.

How we’ve seen EvilTokens being used

mnemonic has tracked EvilTokens-related activity since early March 2026. In the cases reviewed, we observed activity consistent with EvilTokens being hosted or deployed on commodity cloud and hosting infrastructure. That is significant because it shows how threat actors can run phishing operations on widely used platforms that blend into normal internet traffic, complicate reputation-based blocking, and give defenders fewer obvious infrastructure signals to work from.

Our research shows that EvilTokens is advertised and sold on Telegram as a ready-to-use service, combining delivery and operational features such as Office 365 capture links, B2B and SMTP sending, open redirects on legitimate domains, and customer-style support features.

mnemonic has not previously observed device code phishing at this scale. These observations point to a more operational and repeatable form of device code phishing rather than isolated use of the technique.

LLMs and other AI-assisted capabilities in device code phishing

EvilTokens uses LLMs to generate phishing messages and convincing excuses to get a target to start the device code flow. These messages are faster to produce and vary across targets, and are easier to refresh during a campaign. This makes the surrounding workflow cheaper, and more adaptable to its victim’s context.

Our assessment of the platform also indicates that AI and LLMs were used in the development of the platform itself, along with being integrated into the platform to improve operator workflows and automation.

This fits the direction phishing tooling is already moving in. We are seeing LLMs and other AI-assisted capabilities show up in phishing development, campaign setup, and social-engineering content.

This means the barrier to producing credible phishing content continues to fall, and the quality and volume of phishing content can improve without any change to the underlying device code technique.

What mnemonic recommends to mitigate device code phishing

mnemonic recommends treating device code phishing as an identity and session security issue as much as a phishing issue.

We recommend reviewing whether device code authentication is genuinely needed in your environment and restricting it where possible. We also recommend making sure your detections account for token-focused phishing rather than looking only for password theft or classic AiTM tradecraft.

We recommend prioritising the following:

• review device code authentication exposure and restrict it if it is unnecessary
• monitor for suspicious device code authentication activity
• look for anomalous sign-ins from infrastructure linked to known campaigns or kits
• revoke refresh tokens where compromise is suspected, not just reset passwords
• harden Conditional Access and related identity controls around device trust and token use

What can the security community learn from EvilTokens?

EvilTokens illustrates how device code phishing is evolving beyond simple credential theft. It is being packaged and commercialised, and operating at a different scale than we’ve seen previously. These phishing kits lower the barrier to entry by packaging infrastructure, delivery, and operator convenience into services that more threat actors can use.

By exploiting legitimate sign-in flows and prioritising tokens, sessions, and operator efficiency, it highlights a broader shift in the phishing ecosystem, toward identity and session abuse rather than credentials.