OAuth Device Code Phishing Campaigns Surge with EvilTokens Toolkit

4 May 2026

By Rikesh Vekaria, Archa Archa, Hiwot Mendahun, Samantha Clarke and the Mimecast Threat Research Team

Campaign Overview

The Mimecast Threat Research team has identified a significant surge in OAuth device code phishing campaigns targeting Microsoft 365 users across all regions and industries. Since March 2026, over 50,000 malicious email campaigns have exploited Microsoft's legitimate OAuth 2.0 device authorization flow, a mechanism originally designed for devices without keyboards, such as smart TVs and IoT equipment, to steal authentication tokens and compromise cloud-based accounts.

This technique has rapidly become a preferred attack method for threat actors, similar to how ClickFix attacks dominated the threat landscape last year. The accessibility of the attack has been amplified by the emergence of EvilTokens, a Phishing-as-a-Service (PhaaS) toolkit sold on Telegram that automates the entire attack chain. EvilTokens incorporates AI-generated social engineering content, enabling even low-skill attackers to conduct convincing brand impersonation campaigns at scale.

Understanding Device Code Phishing

Traditional phishing attacks attempt to steal credentials by presenting fake login pages that mimic legitimate services. Device code phishing represents a fundamental evolution: rather than impersonating Microsoft's login interface, attackers exploit Microsoft's own authentication infrastructure to obtain real, valid access tokens. The OAuth 2.0 device authorization flow operates as follows in legitimate use:

1. A device (such as a smart TV) generates a device code and displays it to the user
2. The user navigates to microsoft.com/devicelogin on a separate device
3. The user enters the device code and authenticates with their credentials
4. Microsoft issues an access token to the original device, granting it authorized access

In device code phishing attacks, threat actors exploit this flow by:

1. Registering a malicious OAuth application with Microsoft Azure AD
2. Initiating a device authorization flow on their backend infrastructure
3. Obtaining a legitimate device code from Microsoft's authorization servers
4. Presenting this code to victims through phishing emails and fake brand pages
5. Convincing victims to visit the real Microsoft device login page and enter the code
6. Capturing the resulting OAuth tokens when victim completes authentication

Because victims authenticate on Microsoft's genuine infrastructure and the tokens issued are legitimate, this technique bypasses multi-factor authentication, passes all domain reputation checks, and evades traditional phishing detection mechanisms. The attack does not rely on credential capture—it exploits user trust in familiar business workflows to authorize malicious applications.

The EvilTokens Ecosystem

According to research from Sekoia, EvilTokens represents a significant threat actor innovation: a fully automated Phishing-as-a-Service platform that commoditizes sophisticated OAuth abuse. The toolkit provides threat actors with:

• AI-Powered Social Engineering: Automated generation of convincing phishing emails and landing pages that mimic trusted brands and business processes
• Turnkey Infrastructure: Pre-configured backend systems that manage device code generation, victim session tracking, and token harvesting
• Real-Time Monitoring: Dashboard interfaces showing active campaigns, victim interactions, and successful token captures
• Scalability: Capability to launch thousands of simultaneous phishing campaigns with minimal technical expertise. This democratization of advanced attack techniques explains the explosive growth observed since March 2026. Where device code phishing previously required sophisticated technical knowledge, EvilTokens enables any threat actor with basic operational security understanding to conduct enterprise-scale account compromise campaigns.

Campaign Variations

Mimecast Device Enrolment Campaign

This campaign, first observed on April 16th, highlights a concerning development: threat actors have begun impersonating Mimecast's device enrolment process, exploiting the legitimate security workflow customers use to access protected content.

Fake Mimecast Device Enrolment Flow: Recipients receive emails claiming to contain protected documents or links requiring Mimecast device enrolment. When victims click the link, they encounter a page visually identical to Mimecast's device enrolment interface.

1. Initial Page: Displays Mimecast branding with instructions to "Get Authentication Code"
2. Code Display: After clicking the button, the page refreshes and presents a device code directly on the webpage
3. Document Access: A "View Document" button appears, which when clicked, redirects to microsoft.com/devicelogin
4. Authentication Prompt: The real Microsoft page requests the code, instructing users to "input the code visible on their app or device to give full permission to their account"
5. Token Theft: Upon authentication, the attacker's backend captures the OAuth tokens while victims believe they've completed legitimate device enrolment

Legitimate Mimecast Device Enrolment Flow:

Understanding the authentic process is critical for user education and threat detection:

1. User clicks a Mimecast rewritten link in an email which requires device enrolment and is taken to Mimecast's device enrolment page        
2. The webpage requests the user's email address, which will be validated against Mimecast's customer database to confirm they are a legitimate Mimecast user
3. After clicking "Get Device Enrolment Code," the webpage refreshes to display an input field for the enrolment code and lets the user know the code was sent to their email address. NOTE: the code is NOT displayed on the webpage
 
4. User retrieves the code from their email and enters it into the webpage input field
5. Upon successful validation, the user is redirected to the originally requested content.

The critical distinction is that legitimate Mimecast device enrolment never displays enrolment codes directly on webpages. Codes are always delivered via email as a secondary verification channel.

This impersonation is particularly effective because:

• Users expect security workflows when accessing protected content
• Device enrolment appears as a legitimate security requirement
• The visual fidelity of the fake pages closely matches authentic Mimecast branding

DocuSign Document Review Campaign

The most prevalent campaign variation leverages DocuSign brand impersonation, exploiting the widespread business use of electronic signature workflows. Recipients receive emails claiming to require document review or signature, with subject lines such as:

• "DocuSign - Review Document"
• "Agreement_Review.pdf - Signature Required"
• "Urgent: Contract Awaiting Your Signature"

The campaign's effectiveness stems from exploiting a real business process: many organizations do integrate DocuSign with Microsoft 365 for identity verification, making the verification request appear routine rather than suspicious.

Microsoft Teams Voicemail Notification Campaign

Another campaign variation exploits the ubiquity of Microsoft voicemail notifications in enterprise environments. As organizations increasingly rely on unified communications platforms, voicemail alerts have become routine, expected communications that employees rarely scrutinize. Recipients receive emails designed to appear as legitimate Microsoft voicemail notifications, with subject lines such as:

• "You have a new voicemail from [Name]"
• "Missed call - New voicemail message"
• "Microsoft Teams: New Voice Message"
• "Voicemail notification - Action required"

Technical Analysis: Obfuscation and Evasion

Multi-Layer Encryption Scheme

Recent campaigns implement anti-analysis measures to prevent security researchers and automated systems from examining phishing infrastructure. The primary obfuscation mechanism employs AES-GCM encryption with client-side decryption.

Stage 1: Initial Payload When victims first access a phishing URL, they receive an HTML document containing javascript

A small JavaScript loader function decodes the Base64 strings to byte arrays, imports the AES-GCM key using the Web Crypto API, and decrypts the ciphertext using the provided IV.

Stage 2: Dynamic Content Replacement Upon successful decryption, the script replaces the entire HTML document with the decrypted content:

This approach ensures the actual phishing page—containing brand logos, social engineering text, and malicious form elements—remains invisible to:

• Email security scanners that analyze link destinations
• URL reputation services that crawl and analyze pages
• Security researchers performing initial triage
• Automated threat intelligence collection

Only when JavaScript executes in a full browser context does the real phishing content become visible. Static analysis tools examining the HTML source code see only the encrypted payload and loader script.

Stage 3: Backend Coordination The decrypted phishing page communicates with attacker-controlled backend infrastructure to coordinate the device code flow:

Session Initiation:

This request triggers the backend to initiate a legitimate OAuth device authorization flow with Microsoft. The response contains:

• userCode: The real device code obtained from Microsoft's authorization servers
• sessionId: A unique identifier for tracking this victim's session

Status Polling:

The phishing page continuously polls the backend to determine when the victim has completed authentication on Microsoft's platform. When the backend successfully exchanges the device code for OAuth tokens, it responds with status: "completed", triggering the phishing page to display a success message and redirect to the legitimate brand website.

Infrastructure and Hosting

Phishing pages are frequently hosted on:

• AWS S3 buckets: Legitimate cloud storage providing high availability and trusted infrastructure
• Compromised web servers: Existing domains with established reputation to evade blocklists
• Newly registered domains: Low-reputation domains with typosquatting variations of legitimate brands

Backend API endpoints that manage device code generation and token capture operate on separate infrastructure, often utilizing:

• Virtual Private Servers (VPS) from providers offering minimal identity verification
• IP addresses with valid TLS certificates from Let's Encrypt, lending false legitimacy

This separation between visible phishing pages and token-capture infrastructure complicates takedown efforts and attribution.

Indicators of Compromise (IOCs)

DocuSign Campaign

Phishing Domains:

• 00a7af15-a112-4457-86c2-5c56751f0f47-endpoint[.]com
• index-yfb.kpenza-htrenchless-com-s-account.workers[.]dev

Example Subject Lines:

• "DocuSign - Review Document"
• "Agreement_Review.pdf - Signature Required"
• "Urgent: Contract Awaiting Your Signature"
• "Document Pending Your Electronic Signature"

Microsoft Voicemail Campaign

Phishing Domains:

• voice-mail-auth-office-com.saxeco7653.workers[.]dev
• auth-login-office-com.saxeco7653.workers[.]dev
• delicate-poetry-debc.dporozok.workers[.]dev

Example Subject Lines:

• "Voicemail notification - Action required"
• "Missed call - New voicemail message"
• "You have a new voicemail from [Name]"

Mimecast Device Enrollment Campaign

Phishing Domains:

• sso-nodeconnect[.]icu/

Example Subject Lines:

• "View Document"
• "Agreement_Review.pdf - Signature Required"

Targets

Geographic Focus: Global—all regions

Industry Vertical: Cross-industry; particularly effective against organizations using DocuSign, Microsoft , or Mimecast

Recommendations

User Security Awareness Training

• Educate employees on the specific characteristics of these campaigns
• Users should never enter device codes from unsolicited emails, even when the Microsoft login page appears legitimate. Authentic device enrolment workflows from Mimecast and other services follow specific patterns—codes are delivered via email, not displayed on webpages, and never require authentication on Microsoft's device login page.
• Review OAuth application consents. Organizations should audit existing third-party application consents across their Microsoft 365 tenants, identifying and revoking applications with suspicious names, recent authorization dates, or unknown publishers.

Proactive Threat Hunting

• Search email receipt logs using the IOC’s listed

Device code phishing represents a fundamental challenge to cloud-based authentication: the attack exploits legitimate functionality within OAuth 2.0's design, not a vulnerability that can be patched. As Phishing-as-a-Service toolkits like EvilTokens continue to democratize sophisticated techniques, organizations must evolve defences beyond traditional perimeter controls. Microsoft has introduced risk-based authentication policies and application governance features, but ultimate protection requires defence in depth: technical controls that restrict OAuth authorization, user education that recognizes device code abuse, and security operations that rapidly detect post-compromise indicators. The rise of device code phishing underscores that authentication trust models designed for user convenience also create opportunities for social engineering at unprecedented scale.