A phishing kit named EvilTokens is behind a fresh wave of attacks targeting Microsoft 365 accounts in 2026. Offered as phishing-as-a-service, the tool exploits a legitimate OAuth 2.0 mechanism—the device authorization grant flow—to steal access without ever touching a user’s password. Even organizations with strict multi-factor authentication policies are falling victim because the attack works by luring employees into granting permissions to a rogue application, giving attackers persistent, session-level control over corporate data.

Security researchers first noted the kit in early 2026, linking it to multiple campaigns against mid-sized businesses and financial firms. The technique is not new, but EvilTokens lowers the barrier by packaging the exploit in a turnkey web panel that handles code generation, victim communication, and token capture. Microsoft has acknowledged the device code flow’s susceptibility to consent phishing and provides tools to block it, yet many IT teams remain unaware that this authentication route exists—let alone that it can be weaponized.

Understanding the OAuth 2.0 Device Authorization Grant

The device authorization grant was designed for input-constrained devices like smart TVs, gaming consoles, or IoT hardware that lack a browser or easy keyboard input. When an app on such a device needs to authenticate a user, it requests a device code from the identity provider’s authorization server. The device then displays a short alphanumeric code and a verification URL (typically microsoft.com/devicelogin). The user picks up a second device—a phone or laptop—navigates to the URL, enters the code, and authenticates. Once the user approves the sign-in, the original device obtains access and refresh tokens without ever seeing the user’s credentials.

This workflow is completely legitimate and widely used by services like Microsoft 365, Google Workspace, and Xbox Live. The problem arises when an attacker initiates the process on their own machine and tricks someone else into completing the code entry and approval.

How EvilTokens Exploits the Device Code Flow

The attack unfolds in five distinct stages, all of which leverage official Microsoft endpoints. MFA proves useless because the victim actively authenticates and approves a permission request—actions that MFA cannot veto.

  1. Initiation – Using the EvilTokens panel, the attacker triggers a device authorization request against Microsoft’s Entra ID endpoint (login.microsoftonline.com/organizations/oauth2/v2.0/devicecode). The response includes a user code (e.g., ABCD-EFGH) and a verification URL.
  2. Phishing – The attacker immediately sends the victim a tailored message—often via email, SMS, or a chat app like Microsoft Teams—claiming an urgent security update requires them to visit the verification URL and enter the code. The message may spoof internal IT or a trusted vendor.
  3. Code Entry – The victim opens the legitimate Microsoft login page, authenticates with their credentials, and (if enforced) completes MFA. They then see a prompt to grant permissions to an application, which is named deceptively—common lures include “Adobe Document Cloud,” “Workday SSO Integration,” or “Microsoft Teams Meeting Add‑in.”
  4. Consent – If the victim clicks “Accept,” the attacker’s session receives an authorization code, which is immediately exchanged for an access token and a long-lived refresh token. No password is exposed, but the tokens provide the same level of access as the user.
  5. Post‑Exploitation – Armed with valid tokens, the attacker can read mail, download files from SharePoint, access Teams chats, and move laterally within the tenant. Refresh tokens can be used indefinitely unless revoked, giving the attacker persistent foothold until detected.

Because every step takes place on Microsoft’s genuine domains and the victim’s browser, traditional phishing defenses that rely on domain reputation or credential input detection are blind to the attack. Conditional Access policies that require MFA are satisfied, so the malicious application grant sails through.

Why MFA Alone Cannot Stop Device Code Phishing

Multi-factor authentication is designed to ensure that the person logging in is who they claim to be. During a device code attack, the victim is the one logging in. MFA challenges are completed legitimately. The security gap lies in the consent step that follows: Entra ID asks the user to grant specific permissions to the third-party application—permissions like “Read your mail,” “Access your files,” or “Maintain access to data you have given it access to.” Once approved, that application (now controlled by the attacker) holds tokens with those privileges.

Microsoft’s consent framework does incorporate risk signals—unknown publisher warnings, low client reputation, and admin approval requirements for high‑risk permissions. However, EvilTokens operators carefully choose permissions that appear benign or configure the application to mimic well-known brands, often registering legitimate-looking enterprise apps through the Azure Portal. A 2026 analysis of one campaign showed that the fake app was named “Microsoft Corporation – OneDrive Backup” and requested only offline_access and Mail.Read, privileges many users would approve without a second thought.

The 2026 EvilTokens Campaigns: Observed Tactics

Since the kit’s emergence, incident response firms have documented several hallmark patterns:

  • Targeted industries: financial services, legal, healthcare, and higher education—sectors where a single mailbox compromise can yield sensitive data for extortion or wire fraud.
  • Delivery vectors: spear‑phishing emails impersonating Microsoft “Non‑Compliance Notification” alerts, Microsoft Teams direct messages from compromised partner accounts, and even SMS messages directing mobile users to microsoft.com/devicelogin.
  • Lure sophistication: Attackers often include the user’s real name, company logo, and a sense of urgency (“Your account will be blocked in 24 hours”). Some campaigns pre‑populate the code in a QR code, making it trivially easy to scan and follow.
  • Persistence methods: After gaining initial access, attackers use Microsoft Graph API to create hidden mailbox rules, register additional malicious applications with broader permissions, and sometimes open Outlook Web App sessions to maintain interactive access.

One notable incident in March 2026 involved a mid‑sized engineering firm where a single consent grant led to the exfiltration of 75 GB of SharePoint data over a weekend—before the SOC realized that a new enterprise application had been provisioned.

Hardening Microsoft 365 Against Device Code Abuse

Microsoft provides several built‑in controls to block or tightly restrict device code flow. Security teams should prioritize the following measures:

1. Disable Device Code Flow Entirely (If Possible)

If your organization does not use device‑authenticated apps (e.g., television‑based Teams Rooms, gaming consoles), the safest path is to turn off the flow altogether. In the Entra admin center, navigate to Protection > Conditional Access > Authentication flows and create a policy that blocks device code flow for all users. Exclude break‑glass accounts and any known service principals that legitimately rely on the flow.

2. Require Devices to Be Compliant or Hybrid Joined

A broad Conditional Access policy can block device code logins unless the authenticating device is registered and compliant. Since the attacker’s session originates from an unmanaged machine, the token request will fail even after consent. Configure a policy with:
- Target: All cloud apps
- Conditions: Client apps – select Browser and Mobile apps and desktop clients
- Grant: Require device to be marked as compliant or hybrid Azure AD joined

This policy effectively neutralizes device code attacks because the initial token exchange happens from the attacker’s client, which will not satisfy the device state requirement.

3. Adopt the Entra ID “Token Protection” Preview

Token Protection binds access and refresh tokens to the original device through a cryptographic key stored in the operating system’s secure enclave. Even if an attacker obtains a refresh token, they cannot replay it on a different machine. The feature is in public preview as of mid‑2026 and supports Windows, iOS, and Android devices. Enable it from Security > Authentication methods > Token Protection.

EvilTokens relies on users approving an application. Set your tenant’s consent settings to Do not allow user consent or, at minimum, Allow user consent for apps from verified publishers, for selected permissions (low‑risk permissions only). The admin consent workflow ensures that any attempt to register a new application triggers a review request. Supplement this with the Consent and permissions workload in Microsoft Defender for Cloud Apps, which flags unusual consent grants.

5. Monitor Sign‑In Logs for Device Code Events

The Kusto Query Language snippet below, run in Microsoft Sentinel or Advanced Hunting, surfaces device code sign‑ins that resulted in token issuance:

SigninLogs
| where DeviceDetail.operatingSystem == \"Device Code Flow\"
| where ResultType == 0
| project Timestamp, UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress

Look for sign‑ins where the client app is the attacker’s registered application and the user‑agent string does not match corporate‑managed devices. Any successful device code authentication from an unrecognized IP should immediately trigger an investigation.

6. Educate Users as a Last Line of Defense

Include device code flow in regular phishing training. Employees should be taught to never enter a code from an unsolicited message—no IT department legitimately asks staff to visit microsoft.com/devicelogin during a support call. Add a banner to all external emails and set up mail flow rules that warn when messages contain the string “devicelogin.”

Detection and Incident Response

When a device code attack slips through, speed is critical. Follow this triage checklist:

  • Revoke sessions: In the Entra admin center, immediately revoke all sessions for the affected user’s object ID.
  • Remove the malicious app: Navigate to Enterprise applications and delete the attacker‑provisioned app. Check the App registrations blade for any new registrations made with the compromised token.
  • Audit mailbox rules: Use the Microsoft 365 Defender portal to scan for hidden forwarding rules or inbox rules that could exfiltrate data.
  • Check audit logs: Filter unified audit logs for Add OAuth2PermissionGrant and Consent to application operations. This will reveal exactly which permissions were granted and to which app.
  • Contain the tenant: If broad persistence is suspected, activate the Tenant‑Wide Safe‑Links and Session control settings in Defender for Office 365 to limit external communication until the scope is understood.

Microsoft 365 Defender now includes a “Suspicious consent grant” alert that triggers when a user consents to an application that has not been previously seen in the tenant. Ensure this alert is configured with high severity and automated remediation where possible.

Beyond EvilTokens: Securing the Identity Fabric

The rise of EvilTokens underscores a broader shift in phishing tactics. As organizations have widely adopted MFA, threat actors have moved “up the stack” to attacks that exploit legitimate authentication protocols. The device code flow is just one example; the same principle applies to OAuth illumination attacks, SAML injection, and QR code login phishing. Gartner recently predicted that by 2028, 45% of successful account compromises would bypass credential‑based attacks entirely, relying instead on token theft and consent deception.

Microsoft’s identity security roadmap is responding aggressively. The general availability of Microsoft Entra ID Protection risk‑based sign‑in policies now extends to the device code flow, automatically blocking suspicious code redemption attempts. Conditional Access session controls can also interrogate the client application’s publisher domain and grant‑scope combinations, making it harder for EvilTokens operators to slip through unnoticed.

For security practitioners, the lesson is crisp: authentication hygiene is no longer just about strong passwords and MFA prompts. Every OAuth grant type, every token endpoint, every consent interaction must be understood, monitored, and restricted to only what the business genuinely needs. EvilTokens will inevitably evolve—new kits will mimic legitimate business applications more convincingly, and attackers will probe other flows like resource owner password credentials or on‑behalf‑of. The only sustainable defense is a zero‑trust architecture where identity is verified, devices are trusted, and access is granted on the principle of least privilege—at every step of the authentication journey.

In the immediate term, open your Entra ID portal, check which authentication flows are enabled, and ask yourself: if a phishing kit can bypass every control you have in place today by simply asking a user to type in a code, what else is being overlooked?