OAuth Device Code Phishing: How EvilTokens and Kali365 Bypass MFA and What Microsoft 365 Teams Must Do Now

OAuth device code phishing is an account takeover technique that exploits the OAuth 2.0 Device Authorization Grant (RFC 8628) to steal persistent access tokens from Microsoft 365 users, bypassing multi-factor authentication without ever touching the victim's password or MFA code. The attack works because the victim willingly completes a legitimate Microsoft authentication flow: the token is issued to the attacker's client, not to a fake page.

The threat has accelerated sharply in 2026. Push Security's threat research team documented a 37.5x surge in device code phishing pages by April 2026 (attributed to the commercial launch of the EvilTokens PhaaS platform). In May 2026, the FBI's Internet Crime Complaint Center issued PSA IC3-PSA260521 warning enterprise organizations about Kali365, a second Phishing-as-a-Service platform targeting Microsoft 365 tenants at scale. If your organization runs M365 without a Conditional Access policy blocking the device code flow, every user account is exposed.

What OAuth device code phishing is and why MFA does not stop it

The OAuth 2.0 Device Authorization Grant was designed for input-constrained devices: smart TVs, CLI tools, network printers, and IoT sensors that cannot render a full browser session. The standard flow has the device display a short code and a URL (microsoft.com/devicelogin). The user visits the URL on their phone or laptop, enters the code, authenticates normally including MFA, and the device polls until the token arrives.

The security problem is structural. Nothing in RFC 8628 requires that the device requesting the code be the same device the user authenticated from, or even that the requesting device belongs to the user's organization. An attacker can request a device code using any legitimate OAuth client ID, hand that code to a victim via phishing, and then poll for the resulting token. The victim's MFA challenge is genuine, occurs on real Microsoft infrastructure, and succeeds. The token lands in the attacker's polling loop.

This is why MFA does not stop it. The attack does not intercept MFA: it redirects the authentication event so that the attacker's application receives the resulting access and refresh tokens. Those tokens then grant full access to Outlook, Teams, SharePoint, and OneDrive, and they survive a password reset because Microsoft refresh tokens are long-lived and credential-independent.

Stolen OAuth tokens like these will not show up in a typical password breach check, since no password was ever involved. Bitdefender Digital Identity Protection monitors for your accounts and personal data surfacing in breach dumps and dark web marketplaces, a useful early-warning layer alongside the Conditional Access policy that actually blocks the device code flow. See what's exposed about you (affiliate link).

How the attack works: step by step

Step 1: The attacker initiates a device code request. Using a legitimate Microsoft OAuth client ID (or a registered app in any Entra tenant), the attacker calls the device authorization endpoint and receives a user_code such as "BXMK9-P7QRZ" and a device_code. The user_code is valid for 15 minutes by default.

Step 2: The phishing lure delivers the code. The victim receives an email impersonating a DocuSign signature request, a Microsoft Teams voicemail, a SharePoint document share, or a construction bid (Huntress observed all four lure types in the 2026 campaign). The email instructs the user to visit microsoft.com/devicelogin and enter the provided code to "verify their account" or "access the document."

Step 3: The victim authenticates. The user visits the legitimate Microsoft URL, enters the code, and completes their normal sign-in including MFA. From the user's perspective this is indistinguishable from a genuine Microsoft device authorization flow.

Step 4: The attacker's polling loop captures the token. While the victim authenticates, the attacker's backend polls the Microsoft token endpoint every few seconds. The moment the victim completes MFA, the endpoint returns an access token and a refresh token tied to the victim's identity and the attacker's registered OAuth application.

Step 5: Persistent access and lateral movement. Using the refresh token, the attacker can silently renew access tokens for weeks or months. They read email, export contacts, search Teams messages for credentials and wire transfer requests, access OneDrive files, and often register a new authenticator method or OAuth application to maintain a second persistence channel. Forcing a password reset does not revoke the stolen refresh token unless revocation is triggered explicitly.

EvilTokens and Kali365: the toolkits driving the 2026 surge

EvilTokens

EvilTokens launched on the NOIRLEGACY GROUP Telegram channel on February 16, 2026. It is a Phishing-as-a-Service platform that commoditizes device code phishing for non-technical threat actors. Subscribers receive: a Cloudflare Workers frontend for lure delivery, a Railway.com backend that handles OAuth polling and token capture, AI-generated phishing email templates in multiple languages, and a real-time dashboard showing which victims have authenticated. Huntress identified five Railway.com IP addresses responsible for the majority of observed polling traffic, with three IPs accounting for approximately 84% of events, indicating centralized, shared infrastructure.

By March 2026, Huntress was tracking an EvilTokens-attributed campaign that had reached more than 344 organizations across the US, Canada, Australia, New Zealand, and Germany. The Cloud Security Alliance published a research note in March 2026 confirming that EvilTokens had rendered MFA bypass accessible to a significantly lower-skilled attacker pool than required by previous adversary-in-the-middle frameworks like Evilginx.

Kali365

Kali365 was first observed in April 2026 and surfaced in the FBI PSA issued on May 21, 2026 (IC3 PSA260521). It extends EvilTokens-style functionality with additional capabilities: AI-generated targeted phishing lures that personalize content per victim, automated campaign templates for common M365 impersonation scenarios, real-time tracking dashboards for threat actors running concurrent campaigns, and OAuth token capture and replay across multiple Microsoft Graph API scopes.

The FBI noted that Kali365 is primarily distributed and sold via Telegram, lowering the barrier to entry for less-technical criminal actors. Because it operates entirely through legitimate Microsoft infrastructure and OAuth endpoints, the attack surface looks normal to users and most perimeter security controls.

Why Microsoft 365 is the prime target

M365 is the highest-value target for device code phishing for three compounding reasons. First, the Microsoft OAuth ecosystem uses long-lived refresh tokens: a stolen token from the Microsoft Graph API can be renewed for months without requiring additional authentication, giving attackers a persistent foothold that outlasts both password resets and MFA re-enrollment unless token revocation is explicitly triggered.

Second, the M365 scope surface is enormous. A single token scoped to Mail.ReadWrite, Files.ReadWrite.All, Chat.ReadWrite, and Contacts.Read gives an attacker access to the organization's email, file storage, Teams chat, and address book in a single authentication event. Attackers routinely use harvested tokens to search for keywords like "wire transfer," "invoice," "password," and "VPN" across all accessible mailboxes.

Third, the microsoft.com/devicelogin URL carries inherent trust. Security-aware users who would hesitate before clicking an external link readily visit a Microsoft-owned domain and enter a code that looks exactly like the device codes they use for Xbox or Azure CLI sign-ins. This social engineering friction is structurally lower than credential phishing.

The token abuse problem extends beyond human identities. As covered in our guide to non-human identities and AI agent security, OAuth tokens issued to service principals and AI agents face the same long-lived persistence risk, and attackers who compromise a user token can often pivot to service account tokens via delegated permissions in the same M365 tenant.

How to block device code phishing with Conditional Access

The primary technical control is a Microsoft Entra Conditional Access policy that targets the Authentication flows condition and blocks the Device code flow grant type. This policy is available in Microsoft Entra ID P1 and above. Blocking this grant type does not require identifying phishing infrastructure: it prevents the authentication flow itself from completing for unauthorized users, regardless of which PhaaS platform the attacker is using.

Creating the blocking policy

Navigate to Entra ID > Protection > Conditional Access > New policy. Set the following:

Users: All users (with a break-glass account exclusion group). Target resources: All cloud apps. Under Conditions, expand Authentication flows, set Configure to Yes, and check Device code flow. Under Access controls > Grant, select Block access. Set the policy to Report-only first, then move it to On after reviewing the sign-in log impact for 48-72 hours.

Handling legitimate device code use cases

Legitimate device code flow is required for specific scenarios: Azure CLI sign-in on headless servers, Microsoft Teams Rooms devices, and some legacy manufacturing or healthcare hardware. Create a separate named user group for these use cases and exclude it from the blocking policy. Require that members of the exclusion group also satisfy a compliant-device condition or a named location condition limiting device code sign-ins to corporate IP ranges. Document each exception with a business justification. The Microsoft Learn documentation (policy-block-authentication-flows) recommends starting with Report-only mode and auditing existing usage before blocking.

For a full walkthrough of Conditional Access policy design, including naming conventions, policy stacking, and the recommended baseline set, see our Microsoft Entra ID Conditional Access setup guide.

Detection and monitoring

Detection must run in parallel with the blocking policy, both to catch any gaps during the Report-only transition and to identify potential compromises that occurred before the policy was deployed.

Entra ID sign-in logs

In the Microsoft Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs. Filter by Authentication protocol = deviceCode. Any results here represent device code flow usage in your tenant. Export 90 days of this data before deploying your blocking policy to identify users, apps, and locations that currently rely on device code flow legitimately.

The following KQL query detects successful device code sign-ins from unmanaged devices in Microsoft Sentinel or the Entra sign-in logs workbook:

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| where isempty(DeviceDetail.deviceId)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, Location, DeviceDetail

Unmanaged devices (empty DeviceDetail.deviceId) combined with successful device code authentication are a high-confidence indicator of phishing. A managed device completing a legitimate device code flow for Azure CLI will have a populated device ID.

Risky sign-ins and Identity Protection

Microsoft Entra ID Protection (P2 license) raises risk signals for device code flow abuse. The relevant detections are: Unfamiliar sign-in properties (device code sign-in from a new location or device), Anomalous token (token issued to a client that does not match typical patterns for that user), and the recently added Device code flow phishing detection which was added to the risky sign-in catalog following the 2026 surge. Users flagged by these detections should be treated as potentially compromised and remediated with a token revocation, not just a password reset.

Microsoft Defender XDR alerts

In the Defender XDR portal, enable the alert rule "Suspicious device code sign-in" under Microsoft Entra ID Protection alerts. Defender also surfaces post-compromise signals: mass email forward rules created shortly after a device code sign-in, large-scale mailbox searches, OAuth application consent from a newly compromised account, and Teams messages sent from unusual locations immediately following authentication. Correlate these with the AADSignInEventsBeta table in Advanced Hunting for timeline reconstruction.

Beyond Conditional Access: layered defenses

The Conditional Access block is the primary control, but it operates at the authentication layer. A defense-in-depth approach adds controls at the token lifecycle, email delivery, and user awareness layers.

Token lifetime and revocation

Configure token lifetime policies in Entra to reduce the window of stolen token validity. The default refresh token lifetime for non-persistent sessions is 24 hours. For high-value users such as executives, finance, and IT administrators, reduce the sign-in frequency requirement via Conditional Access to force re-authentication every 4-8 hours. When responding to a suspected device code compromise, use the Microsoft Graph API or PowerShell (Revoke-MgUserSignInSession) to revoke all refresh tokens immediately rather than relying on a password reset alone.

Email and phishing lure controls

Device code phishing lures are delivered primarily through email. Enable Microsoft Defender for Office 365 Plan 2 Safe Links with URL detonation. The lure URLs themselves often point to legitimate services (DocuSign, Microsoft Forms, SharePoint) which Safe Links may not block, so add a custom allowed-sender policy to alert on inbound messages containing the pattern "microsoft.com/devicelogin" combined with a code string. Train users specifically on the device code phishing scenario: the legitimate URL and an unusual context (unsolicited document sharing, out-of-hours voicemail) should raise suspicion.

OAuth application governance

Review all OAuth applications with access to your M365 tenant using Entra ID's App registrations and Enterprise applications pages. Investigate any application granted broad Microsoft Graph scopes (Mail.ReadWrite, Files.ReadWrite.All, Chat.ReadWrite) that was not provisioned by your IT team. Post-compromise attackers commonly register a second OAuth application as a persistence mechanism. Enable Microsoft Defender for Cloud Apps to generate alerts on new OAuth applications accessing sensitive data scopes, and configure app governance policies to require admin approval for high-privilege graph consent.

Phishing-resistant MFA

While MFA does not stop device code phishing when implemented with TOTP or push notification methods, deploying FIDO2 security keys or Windows Hello for Business (passkey-based) does add a meaningful barrier. These authenticators bind the credential to a specific registered device and origin, making the token still vulnerable if the device code flow is permitted but reducing attacker success from repeated spear-phishing attempts against the same user. Treat phishing-resistant MFA as complementary to the Conditional Access block, not as a replacement.

Network access controls

Combining the Conditional Access device code block with a zero trust network access architecture that requires compliant device status for M365 access adds another verification layer. Even if a device code token is stolen, a Conditional Access policy requiring a managed, compliant device for subsequent API calls can reduce the blast radius: the stolen token may authenticate the user identity but fail the device compliance check when the attacker's server tries to use it against Graph API endpoints that require a compliant device.

What to do if you suspect a compromise

If sign-in logs or a user report suggests a device code phishing event already occurred, execute these steps immediately:

1. Revoke all sessions and tokens. Run Revoke-MgUserSignInSession -UserId [UPN] in PowerShell or use the Entra admin center (Users > [user] > Revoke sessions). This invalidates all refresh tokens issued to the account. A password reset alone does not revoke previously issued tokens.

2. Audit OAuth application grants. Check all OAuth applications authorized by the compromised user (Entra > Users > [user] > Applications). Revoke consent for any application not recognized by IT. Attackers frequently register a persistence app during the initial access window.

3. Review email forwarding and inbox rules. In Exchange Online PowerShell, run Get-InboxRule -Mailbox [UPN] and check for rules forwarding email externally or deleting items matching attacker-defined criteria. This is a standard post-compromise action within hours of token theft.

4. Search for lateral movement. Pull Teams chat history and email sent by the compromised account in the 24 hours following the device code authentication event. Attackers routinely use compromised M365 accounts to send device code phishing lures to contacts, extending the campaign chain within trusted communication channels.

5. Report to the FBI IC3. Submit a complaint at ic3.gov with the device code details, attacker polling IP addresses from your sign-in logs, and the phishing email header. The FBI PSA specifically requests that organizations report Kali365-related incidents to support broader threat intelligence correlation.

Frequently asked questions

What is OAuth device code phishing?

OAuth device code phishing is an attack that exploits the OAuth 2.0 Device Authorization Grant (RFC 8628) to trick users into authenticating on behalf of an attacker's application. The attacker requests a device code, sends it to the victim via phishing, and collects the resulting access and refresh tokens when the victim completes a genuine MFA-verified sign-in on microsoft.com/devicelogin.

Why does MFA not stop device code phishing?

MFA verifies that the correct user is completing the authentication challenge, but in a device code flow the resulting token is issued to whichever OAuth client ID was used to initiate the request. The attacker controls that client. The victim's MFA challenge is genuine and succeeds, but the tokens land in the attacker's polling loop, not in a browser session belonging to the victim.

How do I block device code phishing with Conditional Access in Microsoft 365?

Create a Conditional Access policy in Microsoft Entra ID targeting All users and All cloud apps. Under Conditions > Authentication flows, enable the condition and select Device code flow. Under Grant, select Block access. Set the policy to Report-only first to audit existing usage, then switch it to On. Create a separate group for any users who legitimately need device code flow for headless or legacy devices and exclude that group from the blocking policy.

What are EvilTokens and Kali365?

EvilTokens is a Phishing-as-a-Service platform launched in February 2026 that automates device code phishing for Microsoft 365, using Railway.com backend infrastructure and AI-generated lures. Kali365 is a second PhaaS platform first observed in April 2026 and flagged in an FBI PSA (PSA260521) issued May 21, 2026. Both platforms are sold through Telegram and include dashboards, campaign templates, and automated OAuth token capture.

How can I detect device code phishing in Microsoft Entra logs?

In Entra ID sign-in logs, filter by Authentication protocol = deviceCode and Result = Success. Combine this with a filter for empty DeviceDetail.deviceId (unmanaged device) to isolate high-risk events. In Microsoft Sentinel, use the SigninLogs table with the KQL query: where AuthenticationProtocol == 'deviceCode' and ResultType == 0 and isempty(DeviceDetail.deviceId). Microsoft Entra ID Protection also raises an Anomalous token risk detection when device code tokens are issued in unusual patterns.

What should I do immediately if a device code phishing attack compromised a user?

Immediately revoke all sessions using Revoke-MgUserSignInSession (a password reset alone does not revoke tokens). Audit and revoke all OAuth application grants from the compromised account. Check for email forwarding rules created after the sign-in event. Review Teams and email sent from the account within 24 hours of compromise for lateral phishing. Then report the incident to the FBI IC3 at ic3.gov.

For a current example of document-led malware delivery and the endpoint response workflow, read the Ousaban banking Trojan campaign analysis.