OAuth Device Code Phishing Campaigns Surge with EvilTokens Toolkit
By Rikesh Vekaria, Archa Archa, Hiwot Mendahun, Samantha Clarke and the Mimecast Threat Research Team ·
Key Points
Over 50,000 device code phishing campaigns observed since March 2026, representing rapid large-scale adoption of OAuth abuse technique
EvilTokens Phishing-as-a-Service (PhaaS) toolkit enables low-skill threat actors to automate Microsoft 365 account compromise via legitimate OAuth device authorization flow
Impersonated brands include DocuSign, Microsoft, and Mimecast device enrolment workflows—all exploiting trusted business processes
Attack bypasses multi-factor authentication (MFA) by obtaining legitimate OAuth tokens through Microsoft's own infrastructure
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:
A device (such as a smart TV) generates a device code and displays it to the user
The user navigates to microsoft.com/devicelogin on a separate device
The user enters the device code and authenticates with their credentials
Microsoft issues an access token to the original device, granting it authorized access
In device code phishing attacks, threat actors exploit this flow by:
Registering a malicious OAuth application with Microsoft Azure AD
Initiating a device authorization flow on their backend infrastructure
Obtaining a legitimate device code from Microsoft's authorization servers
Presenting this code to victims through phishing emails and fake brand pages
Convincing victims to visit the real Microsoft device login page and enter the code
Share this
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.
Initial Page: Displays Mimecast branding with instructions to "Get Authentication Code"
Code Display: After clicking the button, the page refreshes and presents a device code directly on the webpage
Document Access: A "View Document" button appears, which when clicked, redirects to microsoft.com/devicelogin
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"
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:
User clicks a Mimecast rewritten link in an email which requires device enrolment and is taken to Mimecast's device enrolment page
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
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
User retrieves the code from their email and enters it into the webpage input field
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.
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.
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.
Keep your edge in threat intelligence
Join thousands of security professionals using our curated alerts, expert analysis, and campaign IOCs to defend against emerging cyber threats.
