Device Code Phishing

How It Works

The OAuth device authorization flow (RFC 8628) was designed for input-constrained devices — smart TVs, printers, CLI tools — that can’t display a full web browser. The flow works like this:

1. The device requests a code. An application calls Microsoft’s /devicecode endpoint and receives a short user code (e.g., K9X7M2) and a verification URL.
2. The user enters the code. The user visits https://microsoft.com/devicelogin on a separate device and enters the code.
3. The user authenticates. The user completes sign-in — including MFA — on the real Microsoft page.
4. The device polls for tokens. The application continuously checks whether the user has completed the flow. When they do, Microsoft issues OAuth access and refresh tokens to the application.

Attackers abuse this by:

• Initiating a device code request with an attacker-controlled application registered in Azure AD.
• Sending the user code to the victim via phishing email, Teams message, or SMS: “Enter code K9X7M2 at microsoft.com/devicelogin to view the shared document.”
• Waiting for the victim to complete sign-in and MFA — the attacker’s application receives the tokens.
• Using the tokens to access Outlook, OneDrive, Teams, SharePoint, and other Microsoft 365 services.

The key insight: At no point does the victim see a fake login page. The URL is login.microsoftonline.com. The TLS certificate is valid. The MFA prompt is real. Every security indicator the user has been trained to check passes. The victim is handing tokens directly to the attacker’s device.

Why It Bypasses MFA

Traditional credential phishing captures a username and password. MFA stops this because the attacker lacks the second factor.

Device code phishing is different:

• It steals tokens, not passwords. Once the victim completes authentication — including MFA — the attacker receives a fully-authorized access token. The MFA has already been satisfied.
• The refresh token persists. Microsoft 365 refresh tokens typically remain valid for 90 days by default. The attacker maintains access without re-authenticating.
• It looks like the victim’s own sign-in. The sign-in log shows the victim’s correct location, device, and MFA method. The only anomaly is the requesting application.

The Kali365 Platform

The FBI’s May 2026 public service announcement flagged Kali365 as a phishing-as-a-service (PhaaS) platform specifically designed for device code phishing against Microsoft 365:

• Subscription model. Attackers pay a fee to access the platform — no technical skill required to run campaigns.
• Automated token harvesting. The platform automates the device code request, polling, and token storage.
• Persistent access dashboard. Attackers see active tokens, account details, and can browse victim mailboxes through a web interface.
• Scale. A single campaign can target thousands of users simultaneously.

Detection

KQL query for Azure Sentinel / Microsoft Defender:

AADSignInEventsBeta
| where AuthenticationRequirement == "multiFactorAuthentication"
| where AuthenticationProtocol == "deviceCode"
| project TimeGenerated, UserPrincipalName, IPAddress, UserAgent,
          AppDisplayName, DeviceDetail, Location

Response

1. Revoke tokens immediately. In Azure AD, revoke all refresh tokens for the affected user: Revoke-AzureADUserAllRefreshToken -ObjectId <user>.
2. Disable the user account temporarily while investigating scope of access.
3. Audit the attacker’s activity during the compromised window:
   • Mailbox access (message read/send events in Unified Audit Log)
   • File access (OneDrive/SharePoint audit)
   • Mail forwarding rules and inbox rules
4. Remove the attacker’s application registration from Azure AD if it was registered in your tenant.
5. Review consent grants. Check for unauthorized OAuth consent grants at https://admin.microsoft.com > Settings > Integrated Apps.
6. Notify affected contacts. If the attacker sent phishing emails from the compromised account, notify recipients — they may be the next targets.

Prevention

• Block the device code flow for users who don’t need it: Azure AD Conditional Access → grant controls → require “approved client app” or block authentication flows you don’t use.
• Restrict application consent to verified publishers only. Users should not be able to consent to applications from unverified publishers.
• Enable risk-based Conditional Access to challenge sign-ins with unfamiliar user agents or anomalous device code requests.
• User training. Teach users: If you didn’t initiate a sign-in on your own device, never enter a code at any login page.

Related

• Phishing — detection and response for T1566 techniques
• MFA Fatigue — detection and response for T1110.004, T1621 techniques
• Suspicious Authentication — detection and response for T1078 techniques
• Cloud Account Compromise — detection and response for T1525 techniques
• SaaS Takeover Response — detection and response for T1078 techniques

Sources

• FBI PSA: Kali365 Phishing-as-a-Service Platform
• Malwarebytes: Kali365 phishing kit bypasses MFA
• Microsoft: OAuth 2.0 device authorization grant
• MITRE ATT&CK: T1528 — Steal Application Access Token
• MITRE ATT&CK: T1566 — Phishing