New widespread EvilTokens kit: device code phishing as-a-service

New widespread EvilTokens kit: device code phishing as-a-service Log in Username or Email Address Password Remember Me Forgot password? Search the site... Search for All categories Threat Research & Intelligence Product News SOC Insights & Other News Detection Engineering Reset Threat Research & Intelligence New widespread EvilTokens kit: device code phishing as-a-service – Part 1 Quentin Bourgue and Sekoia TDR March 30 2026 0 20 minutes reading This post was originally distributed as a private FLINT report to our customers on 25 March 2026. Introduction In March 2026, through our monitoring of phishing-focused cybercrime communities, Sekoia’s Threat Detection & Research (TDR) team uncovered EvilTokens, a new turnkey Microsoft device code phishing kit sold as Phishing-as-a-Service (PhaaS). These phishing pages have been circulating since mid-February 2026, and were rapidly adopted by cybercriminals specialising in Adversary-in-the-Middle (AitM) phishing and Business Email Compromise (BEC). Our analysis showed that EvilTokens provides a turnkey Microsoft device code phishing kit and a range of advanced features to conduct BEC attacks , including access weaponisation, email harvesting, reconnaissance capabilities, a built-in webmail interface, and AI-powered automation . The EvilTokens PhaaS operates through fully featured bots on Telegram and continuously improves its phishing kit with new capabilities. In the near future, the operator intends to extend support to Gmail and Okta phishing pages. Given EvilTokens’s rapid adoption, advanced phishing capabilities, and BEC task automation, TDR analysts assess with high confidence that this kit will become a serious competitor in the phishing and BEC landscape . This report explains the Microsoft device code authorisation flow and offers a technical analysis of the EvilTokens device code kit, covering its phishing pages, the weaponisation of harvested Microsoft tokens, and the functionalities available to affiliates. It also highlights the widespread adoption of EvilTokens by analysing delivery campaigns, and the large adversary’s infrastructure. In a follow-up blog post, we will detail the PhaaS operations on Telegram and the additional services provided by the operator eviltokensadmin . It will highlight the advanced features that significantly facilitate BEC fraud by leveraging AI. Device code phishing and its impact To compromise Microsoft 365 accounts, EvilTokens pages rely on device code phishing, a technique that differs from the common AitM tactic of replicating Microsoft authentication pages. In this attack, victims are tricked into entering a device code on the legitimate login page, thereby granting attackers access to their accounts. Microsoft device code authentication flow The OAuth 2.0 Device Authorisation Grant enables authentication for endpoints with limited input capabilities, such as smart TVs, IoT devices, or printers. Rather than requiring a direct local login, the authentication flow delegates sign-in to a secondary host: the endpoint displays a user code, which the user enters in a browser on a separate device, typically a smartphone or computer, to authenticate. Once succeeded, the endpoint receives an access token and refresh token, resulting in a long-lived authenticated session on the device. Microsoft’s implementation of this flow uses three endpoints: POST /oauth2/v2.0/devicecode : the device requests a code ( user_code ), which is alphanumeric characters associated with a session identifier ( device_code ), for a specified client and a scope. GET /devicelogin redirecting to /common/oauth2/deviceauth : the user signs in on a secondary host, by entering the user_code and authenticating using a common method. POST //oauth2/v2.0/token : the device polls this endpoint to obtain the access token ( access_token ) and refresh token ( refresh_token ) granting a persistent access without re-authentication, once the user has authenticated. The refresh token is obtained when the offline_access scope is included in the authorisation request, The following diagram illustrates this protocol, as provided by Microsoft 1 : Device code phishing attack The device code phishing attack exploits the inherent separation between the device to authenticate and the user sign-in in the OAuth 2.0 Device Authorisation Grant detailed above. Rather than relying on an adversary infrastructure, the attacker initiates a genuine device authorisation request to obtain access to the target’s account. By acting as the device’s client, the attacker tricks the victim into completing the standard authentication, taking advantage of the victim’s lack of knowledge regarding device code authentication, and thereby stealing the access grant. Main steps of device code phishing attack are: The attacker sends a valid POST request to /oauth2/v2.0/devicecode using a legitimate client_id ( e.g. a Microsoft first-party application, for example Microsoft Office client). The server returns a device_code , user_code , and the verification_uri . The attacker relays the user_code and verification_uri to the target. For this step, a social engineering lure must prompt the target to authenticate to the legitimate Microsoft URL delivered by the attacker by entering the user_code. The target browses the verification_uri which is a legitimate Microsoft endpoint hxxps://microsoft[.]com/devicelogin , redirecting to: hxxps://login.microsoftonline[.]com//oauth2/v2.0/devicecode. The target enters the user_code delivered by the threat actor through the phishing page or another means, and completes authentication on the Microsoft sign-in page. The attacker polls the //oauth2/v2.0/token to retrieve a valid access_token and refresh_token upon the target’s authentication. The following diagram illustrates steps of a Microsoft device code phishing attack, between the attacker, the victim, and Microsoft authentication services: A Microsoft device code phishing attack aims for the attacker to harvest an access token for the specified application, and a refresh token tied to the device. Access token This short-lived token issued by Entra ID grants access to a target resource for 60-90 minutes, randomly determined. It is tied to the authenticated user, the authorised permission scopes, and the target resource. → In a device code phishing attack, an access token gives the threat actor immediate, direct access to the victim’s resources with no further authentication. Refresh token This Entra ID token allows silent acquisition of new access and refresh tokens for 90 days (except in single-page applications and email one-time passcode flows). A refresh token is “rolling”, issuing a fresh 90-day token on each use and invalidating its predecessor. Additionally, a refresh token can register a device in Entra ID, a prerequisite for requesting a Primary Refresh Token (PRT). → Attackers steal refresh tokens to maintain persistent access to the victim’s account. Primary Refresh Token (PRT) This long-lived token enables 90-day Single Sign-On (SSO) across the account’s applications. It is exchanged via token broker to request access and refresh tokens, permitting silent authentication to Microsoft and other cloud applications, with no further authentication. The PRT is a device-bound SSO artifact. Post-compromise, persistence and impact Below is an overview of the potential post-compromise activities following a successful Microsoft device code phishing attack and their impact. By leveraging the short-lived access token, the attacker can exfiltrate targeted user data for up to 60 minutes following the device code phishing attack. Depending on the targeted service, the attacker can access emails via Exchange Online, documents from Microsoft SharePoint Online and OneDrive, or conversation history in Microsoft Teams. To establish persistence, the refresh token obtained during the device code phishing attack can be redeemed for new access tokens. With its rolling 90-day validity, this token allows the threat actor to maintain continuous access to the compromised account as long as the token is actively renewed and not revoked, without triggering any interactive authentication challenge. In more advanced post-compromise scenarios, the attacker can leverage the harvested refresh token to register an additional device in Entra ID, then use the token together with the new device identity to request a PRT. Once a PRT is obtained, the threat actor can silently authenticate as the victim to the organisation’s Microsoft 365 applications, bypassing credential prompts and MFA, and move laterally to other services and resources beyond those originally targeted. EvilTokens: device code phishing at scale As of March 2026, no major phishing kit includes device code phishing pages. Instead, most Phishing-as-a-Service platforms rely on Adversary-in-the-Middle phishing to target Microsoft 365, Google Workspace, and other services. By contrast, EvilTokens PhaaS distinguishes itself by providing device code phishing pages along with the suite of tools needed to execute account takeovers and post-compromise activities. EvilTokens phishing pages The EvilTokens PhaaS offers customers self-hosted phishing pages designed for device code phishing attacks. These phishing templates include: A decoy page impersonating a Microsoft service or trusted application ( e.g. Adobe Acrobat or Docusign), prompting users to verify their identity to access a document. A verification code (the user_code from the Microsoft device code authorisation flow) for the user to copy. Instructions to complete identity verification via Microsoft. A “ Continue to Microsoft ” button that redirects to the legitimate Microsoft device login page (the verification_uri in the OAuth flow). When the user copies the verification code and clicks on the “ Continue to Microsoft ” button, the phishing page opens the genuine Microsoft device sign-in in a pop-up window. After the user enters the verification code, they are redirected to the standard Microsoft authentication sign-in page. Upon successful sign-in, the attacker’s device receives access to the victim’s account for the targeted service. The figure below illustrates an EvilTokens phishing pages impersonating Adobe Acrobat Sign and launching the device authorisation pop-up: Of note, the Microsoft device login page warns: “ Do not enter codes from sources you don’t trust ”. This phishing tactic relies on impersonating a trusted service so that users overlook the warning and complete the device code authentication. The page then indicates that someone is signing in on another device in the same country as the phishing kit and instructs users to close the page if they do not recognise the device. The user_code is requested by the PhaaS backend from the Microsoft API and remains valid for 15 minutes after the victim loads the phishing page. To obtain this code, the phishing page sends an HTTP POST to /api/device/start , which returns the user_code and a session ID. The phishing page then polls /api/device/status/ to check the authentication status. Once the code is redeemed, the page automatically redirects the user to the predefined URL, usually related to the original lure. Phishing templates As of March 2026, EvilTokens PhaaS includes a range of phishing templates that impersonate Adobe Acrobat Sign and Adobe Acrobat Viewer, DocuSign, email quarantine notices, calendar invites, SharePoint access request, voicemail notifications, password expiry warnings, OneDrive shared document, and eFax notification. All these templates are designed to lure users into completing a Microsoft device code sign-in flow, whether to access a protected document, review a security alert, respond to a meeting invitation, or listen to a voicemail. This social engineering technique relies on users’ lack of awareness about Microsoft device authorisation and the full account access it grants. The HTML for these phishing pages is an empty

and a