Executive Summary
A recent wave of device code phishing attacks, spurred by the phishing-as-a-service toolkit EvilTokens, has been seen impersonating several trusted services. These campaigns are notable for abusing the OAuth 2.0 device authorization flow, automating this sophisticated phishing at scale, and using AI to produce realistic, quickly deployable attack infrastructure. Netcraft has found and disrupted several examples in the wild and compiled a breakdown of what we are seeing. Additionally, Netcraft is taking action against a related attack type, GhostPairing, which applies the same underlying technique — abuse of post-authentication authorization — to secure-messenger pairing.
Device Code Phishing with EvilTokens
This attack type abuses OAuth to give attackers authenticated sessions with victim accounts without them having to perform authentication on their end. When an attacker has confirmed an account of interest exists, such as by checking with the GetCredentialType endpoint on login.microsoftonline.com, they can send a lure to the target. The lure may contain a URL or attachment “requiring authentication”. The malicious lure will show the user a device code for the service that the threat actor wishes to access. The victim is prompted to enter this code at the legitimate verification URL (e.g. microsoft.com/devicelogin) while signing in. When they do, the authorization server issues access and refresh tokens to the attacker's client, which has been polling the token endpoint — giving the attacker ongoing API access under the victim's identity.
This attack flow can allow the attacker to target services used as common third-party logins. For example, the following attack targets Microsoft 365 as a login option for Docusign.
Bringing Scale to this Attack with EvilTokens
While this attack type has been executed before, the EvilTokens toolkit expedites, simplifies, and personalizes these attacks at scale. This increases the likelihood that users will authorize the attacker without finding friction that may make them question the legitimacy of the lure.
The format of embedding the device code into the lure page means that the code is only requested at the time that a user clicks through to the lure. Microsoft device codes expire after 15 minutes (other identity providers vary), and in naive campaigns the code embedded in a phishing email has often already expired by the time the victim opens it. Generating the code on page-load resets that clock. This is in addition to the deliberate defenses Microsoft has added for device code flow abuse, such as the Conditional Access policy that blocks the flow entirely for users who don't need it. This streamlined approach keeps victims engaged with a responsive page that automatically copies the device code to their clipboard, lowering friction and wait time. In some cases, the device code will be generated once the user checks a box to indicate that they aren’t a bot, reducing device code generation attempts to sessions where the user is already interacting with the site.
It is clear that EvilTokens attacks also use responsive web design to target mobile users. Both examples below target Microsoft credentials.
Identifiable Clusters
At time of reporting, Netcraft has identified thousands of attacks using the EvilTokens phishkit. Within this data, several identifiable clusters have been noted. Though these have not always been attributable to a single threat actor, they show varied approaches and markers of different campaigns.
Auth038362
This cluster uses several domains which appear to be legitimately registered by the same actor but then compromised through shared infrastructure.
URLs in the Auth038362 Cluster
|
These domains all appear to be related to a jiu jitsu school in Peterborough, Canada. The school itself appears to now be using a different domain, still run through WordPress which has not been compromised. The 404 page indicates that technical issues may have been a recurring problem for them before.
These sites currently serve a WordPress parking page but previous fetches returned an Azure-hosted "human check" front page that has been observed across multiple EvilTokens sites.
Preliminary analysis has shown that this page has multiple anti-analysis mechanisms, including disabling right click and multiple layers of obfuscation in JavaScript. After the first layer of obfuscation, it can be seen that the site will collect information about the host through ipinfo.io.
In its current state, the script does not seem fully implemented and complete. Some of the operations are obfuscated and others are clear. Some functionality has implemented but parts are commented out for now.
Requests For Quote Cluster
In Netcraft's dataset, several EvilTokens-related domains included 'rfq' in their domain name, indicating that the lure was likely a request for a service or product quote from the target.
Example domains in the Requests for Quote cluster
|
|
RFQ lures were also used without related domains, sometimes being hosted on services like workers.dev, such as in the example below.
URLs in this group contain 'rfq' or 'bidforproject'. They are not necessarily operated by the same threat actor that registered the RFQ domains but show evidence of using the same or very similar lures.
Voicemail Cluster
One small but notable cluster has the specific lure of voicemails and audio files. This is not currently being confidently attributed to a single threat actor but is being tracked as a group due to the specific and uncommon lure.
What makes this lure stand out among the others is the direct impersonation of Microsoft, rather than suggesting third-party OAuth, and the imitation of Microsoft’s Cloud Voicemail service specifically. This indicates a focus on enterprise environments where this functionality would be present.
AI Attack Infrastructure
Microsoft’s report of observed activity related to EvilTokens alleges generative AI use. Netcraft hasn't independently confirmed this, but the role-aligned personalisation we've observed in the lures is consistent with it. Netcraft has previously reported on AI-assisted threat infrastructure generation in phishing campaigns as well as ✨subtle✨ indicators of AI use left in these malicious sites.
GhostPairing
GhostPairing is a campaign using similar tactics to target secure messenger accounts. Messengers like WhatsApp and Signal let users add a linked device by scanning a QR code that encodes a pairing secret; once the primary device scans it, the new device is authorized to send and receive messages on the account. In the GhostPairing campaign, the attacker fetches a legitimate pairing QR from the target service and presents it to the victim on a lure page. When the victim scans it — believing they're linking their own new device — they instead link the attacker's client to their account. The example below is from an attack targeting WhatsApp accounts. Netcraft took down the associated phishing relay infrastructure for this scam in March 2026.
The Dutch General Intelligence and Security Service (AIVD) has reported that some Russian state threat actors have used this approach to target the Signal and WhatsApp accounts of “dignitaries, military personnel, and civil servants”. Though not conclusively identified as the same campaign, Microsoft also reported similar activity from the Russia-linked Storm-2372 targeting Signal, WhatsApp, and Teams.
Conclusion
Device code phishing and GhostPairing both evade the protections against credential theft by aiming to gain control of accounts through post-authentication authorization mechanisms. While attacker adoption of these techniques has only been explored in the last few years, this technique is likely to continue gaining adoption to take advantage of third-party login ecosystems and easy device pairing. The nation-state use of these attacks has so far only been publicly attributed to Russia. However, this is unlikely to remain the case as adoption continues. Additionally, attribution is likely to become more difficult as a result of the availability of sophisticated commercial toolkits like EvilTokens.
Authorization ≠ Authentication
OAuth is an authorization mechanism, assigning access based on identity. It is not intended to be an authentication mechanism, proving that identity in the first place. The use of device codes may look like two-factor authentication. It isn't. Authentication happens through other mechanisms before OAuth assigns permissions based on the established identity. OAuth can carry an authenticated session forward after authentication happens elsewhere, but it doesn't add any security to the authentication step itself. As seen in these attacks, it certainly didn’t provide phishing resistance.
For phishing-resistant authentication, service providers may wish to move toward passkey logins. Passkeys are built on the FIDO2 and WebAuthn standards, which have phishing resistance built in at their core. If switching to passkeys, see Netcraft’s guide to potential pitfalls and attack surface changes to expect during the transition.
