No Fake Login, No Password Theft: Phishing 2026 Operates in a Completely New Way

Summary of the campaign

Recently, a phishing campaign using the OAuth Device Code Flow (automated by the EvilTokens tool) was recorded, targeting over 340 organizations using Microsoft 365. This allowed attackers to completely bypass traditional MFA mechanisms. Instead of stealing credentials, this method tricks users into granting access consent to a malicious app masquerading as a legitimate internal application.

Rủi ro lớn nhất là kẻ tấn công thu thập được Refresh Token có thời hạn dài, duy trì quyền truy cập vào hộp thư (Exchange Online), tệp tin (SharePoint/OneDrive) và dữ liệu nhạy cảm mà không cần tương tác thêm với nạn nhân. Các tổ chức phụ thuộc hoàn toàn vào SMS OTP hoặc Authenticator App mà thiếu kiểm soát ứng dụng OAuth (Enterprise Applications) có nguy cơ bị xâm nhập cao nhất. Hành động khẩn cấp nhất lúc này là rà soát toàn bộ các ứng dụng bên thứ ba đã được cấp quyền trong Azure AD và cấu hình Conditional Access để chặn luồng Device Code nếu không thực sự cần thiết.

Event timeline

Event timeline	Event
February 2026	The Phishing-as-a-Service (PhaaS) platform called "EvilTokens" began appearing on the underground market, fully automating the abuse of the OAuth Device Code flow.
March 2026	The number of phishing pages using the Device Code Flow surged dramatically (reaching a 37.5-fold increase by early April 2026).
25/03/2026	The Cloud Security Alliance (CSA) released its first report warning that this campaign has successfully infiltrated over 340 Microsoft 365 organizations worldwide.
20/05/2026	The CSA updated its detailed report on EvilTokens, warning about a new feature that uses large language models (LLM) to automate email classification and deploy BEC attacks on a large scale.

Attack process

The attack process exploiting the OAuth Device Code Flow through the EvilTokens toolkit is carried out through a coordinated sequence of protocol techniques and social engineering.

The first stage is initiating the request (Device Code Request): Here, the attacker uses the EvilTokens tool to send a device authentication request to the Microsoft Identity Platform, posing as a legitimate application (e.g., Microsoft Office). Microsoft responds with a short display code (user_code) and a session identifier (device_code).

After creating the request, the attacker attempts to lure the victim by sending a phishing email impersonating an IT system notification (such as a device verification request or a routine security upgrade). The email provides the official Microsoft link (https://microsoft.com/devicelogin) along with the previously generated user_code. Here, the EvilTokens tool automatically sets up a polling task that continuously sends requests to the Microsoft token endpoint at fixed intervals (usually every 5 seconds), using the device_code to check the victim's authentication status.

Sau đó, nạn nhân nhấp vào liên kết của Microsoft, nhập mã người dùng, đăng nhập và hoàn tất xác thực hai yếu tố. Vì trang web thuộc miền của Microsoft, không có cảnh báo bảo mật nào. Tiếp theo, nạn nhân nhấp "Chấp nhận" để phê duyệt các quyền. Ngay khi nạn nhân đồng ý, yêu cầu tiếp theo từ máy chủ EvilTokens của kẻ tấn công sẽ được Microsoft trả lời bằng một cặp mã thông báo hợp lệ: access_token (ngắn hạn) và refresh_token (dài hạn).

The attacker uses the refresh_token to maintain long-term access without the user's password or MFA. EvilTokens integrates large language models (LLM) to quickly scan the victim's mailbox, searching for financially sensitive email threads (invoices, payments) and automatically crafting/sending phishing emails for business email compromise (BEC) with high accuracy.

Detailed technical analysis

The nature of this technique involves the deliberate misuse of the OAuth 2.0 Device Authorization Grant protocol (RFC 8628). This protocol was originally designed to support devices with limited input capabilities or without a browser (such as Smart TVs, printers, IoT devices) to log into enterprise accounts.

RFC 8628 protocol

When initiating the attack flow, EvilTokens sends a POST request to Microsoft's device authentication endpoint:

Where:

client_id: The attacker uses a valid Microsoft Office App ID (d3590ed6-52b3-4102-aeff-aad2292ab01c) to disguise the application's origin, making the victim believe this is a standard office service login prompt.
scope: The requested permissions include reading emails (Mail.Read), accessing documents (Files.ReadWrite.All), and specifically the offline access permission (offline_access) to obtain the refresh_token.

Microsoft Identity Platform returns the JSON structure:

EvilTokens saves the device_code to perform polling and extracts the user_code (OTJRY5WQD) to embed in phishing emails sent to the victim.

Polling and Token Theft Process

The attacker runs a script that continuously sends requests to the /token endpoint every 5 seconds (according to the returned interval parameter):

While the victim has not yet entered the code, Microsoft will respond with a 400 Bad Request error code along with the message authorization_pending. As soon as the victim enters the code OTJRY5WQD at microsoft.com/devicelogin and completes MFA, Microsoft verifies that session linked with the device_code. On the next polling attempt by EvilTokens, Microsoft responds with a 200 OK status, providing both the Access Token and the fully privileged Refresh Token.

This security bypass method has technical advantages over traditional phishing techniques: Cannot be blocked by URL Filtering/Secure Email Gateway: The phishing email directs the victim to the legitimate Microsoft domain (microsoft.com). Email filters or Web Proxy solutions cannot block or classify this URL as malicious.

Completely bypass MFA: Since the victim directly logs in and approves MFA in their own browser, even the most robust MFA solutions (like Authenticator App, SMS OTP, or even FIDO2 security keys) cannot detect any anomalies because the authentication flow appears entirely legitimate. Bypass Password Reset: The critical danger lies in the operation of the Refresh Token in Azure AD. When a user changes their password, Azure AD revokes the browser's session cookies, but the Refresh Tokens issued to third-party OAuth applications remain valid. The attacker can continue generating new Access Tokens to access data without needing the victim's new password.

IOC

Detecting this campaign requires a thorough analysis of Azure AD (Microsoft Entra ID) Audit Logs and Sign-in Logs.

Azure AD Audit Logs

Search for events where users grant permissions to unfamiliar applications or have unusual permission scopes (offline_access, Mail.ReadWrite, Files.ReadWrite.All):

Activity: Consent to application or Add app role assignment to service principal
Application ID abused: Review applications using Microsoft's First-party Client ID such as:
- Microsoft Office: d3590ed6-52b3-4102-aeff-aad2292ab01c
- Microsoft Teams: 1fec8e78-bce4-4aaf-ab1b-5451cc3e7264

Filter logins using the Device Code Flow protocol:

Authentication Protocol: Device Code
Original Transfer Method: deviceCodeFlow
Anomalous Location: Check for geographic inconsistencies. Typically, this occurs when the IP address initiating the code request (IP of the EvilTokens server) is in a completely different country from the victim's IP address when they enter the code and authenticate MFA. Since EvilTokens uses low-cost hosting providers to run PhaaS, review authentication connections from the IP ranges of cloud service providers (DigitalOcean, Linode, AWS, OVH) instead of the usual consumer telecom IP ranges.

MITRE ATT&CK Mapping

T1528 - Steal Application Access Token: The attacker collects Access/Refresh Tokens after the victim authenticates. T1524 - Trust Discovery / Consent Grant: Exploiting user trust to request application permissions (Illicit Consent Grant). T1556 - Modify Authentication Process: Bypassing the multi-factor authentication flow by redirecting MFA operations to the victim's side.

Yara Rule

rule phishing_eviltokens_phishing_page {
    meta:
        malware = "EvilTokens"
        description = "Find EvilTokens device code phishing pages based on characteristic strings"
        source = "Sekoia.io"
        creation_date = "2026-03-05"
        modification_date = "2026-03-05"
        classification = "TLP:CLEAR"
        reference = "https://blog.sekoia.io/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1/"


    strings:
        $html = "<!DOCTYPE html>" ascii

        $str01 = "<div id=\"r\">" ascii
        $str02 = "function f(s){" ascii
        $str03 = "return Uint8Array.from(atob(s),x=>x.charCodeAt(0))" ascii
        $str04 = "var k=await crypto.subtle.importKey(" ascii
        $str05 = "var p=await crypto.subtle.decrypt(" ascii
        $str06 = "name:\"AES-GCM\",iv:f(b)" ascii
        $str07 = "document.write(new TextDecoder().decode(" ascii
        $str08 = "document.body.innerHTML=\"Loading failed\"" ascii
        $str09 = "document.close()}catch(e)" ascii

    condition:
        $html at 0 and
        6 of them and filesize < 50KB
}

Expert opinion

The surge in OAuth Device Code campaigns shows a clear shift in the techniques of attack groups: as organizations in Vietnam and around the world have widely adopted MFA, credential phishing no longer holds much value. Instead, "Token is the new credential."

Traditional MFA is creating a false sense of security. In recent Incident Response efforts, SOCs have noted that end users often unconsciously click "Accept" when they see the familiar Microsoft login interface, despite the application requesting full access to their mailbox. Defense cannot rely solely on endpoints or networks; it must shift to identity, specifically by tightly controlling the attack surface of Enterprise Applications.

Recommendation

Immediate (0-24h)

Disable the Device Code Flow if the organization does not use IoT/Smart TV devices requiring M365 authentication. Configure this through Azure AD Conditional Access policy by blocking the "Device code flow" condition.
Query the Unified Audit Log to find Consent to application events from the past 30 days and revoke the permissions of any applications not approved by IT.

Short-term (1-7 days)

Change the Azure AD "User consent settings" to Do not allow user consent. Require all third-party application permission requests to go through the Admin Consent workflow.
Run the PowerShell script Get-AzureADPSPermissions.ps1 to audit all existing OAuth permissions (Delegated and Application permissions) in the tenant.

Long-term

Implement Continuous Access Evaluation (CAE) so the system can revoke tokens almost immediately if unusual changes are detected (such as changes in IP address or device).
Conduct security awareness training for employees: Specifically warn about phishing schemes involving code entry at microsoft.com/devicelogin.

Recommendation

EvilTokens: an AI-augmented phishing kit for automating BEC fraud

EvilTokens Emerges as New Phishing-as-a-Service Platform for Microsoft Account Takeover

The New Phishing Click: How OAuth Consent Bypasses MFA

No Fake Login, No Password Theft: Phishing 2026 Operates in a Completely New Way

Summary of the campaign

Event timeline

Attack process