Listen to this Post
Introduction:
A legitimate authentication protocol designed for smart TVs and IoT devices has become a threat actor’s preferred backdoor into Microsoft 365 environments. The OAuth 2.0 Device Authorization Grant flow, intended for devices without keyboards, is now being weaponized at scale through phishing-as-a-service platforms like EvilTokens, allowing attackers to steal persistent access tokens and fully bypass both passwords and multi-factor authentication (MFA).
Learning Objectives:
- Understand how the OAuth Device Code Flow works and why it is vulnerable to phishing abuse.
- Identify the five-phase attack flow and the role of PhaaS toolkits (EvilTokens) and AI-assisted automation.
- Implement detection and mitigation strategies using conditional access policies, SIEM rules, and token revocation procedures.
You Should Know:
- Anatomy of a Device Code Phishing Attack: Step‑by‑Step Breakdown
The abuse of the OAuth Device Authorization Grant relies entirely on legitimate Microsoft infrastructure, leaving no malicious domains or fake login pages for traditional security tools to detect.
Step 1 — Attacker Registers Malicious OAuth App & Requests Device Code
The attacker registers an application in Microsoft Entra ID (formerly Azure AD) and sends a POST request to Microsoft’s device authorization endpoint (/devicecode) to obtain a unique device code and user code pair.
Step 2 — Phishing Lure Delivers the Code
The user code is embedded into a convincing phishing email, QR code, or voice call (vishing). Common lures include fake “document access requests,” “electronic signing prompts,” or “urgent payment confirmations.”
Step 3 — Victim Enters Code on the Real Microsoft Login Page
The victim is directed to `https://microsoft.com/devicelogin` (the genuine Microsoft domain) and enters the attacker-supplied code. Because this is a legitimate Microsoft page, no certificate warnings or browser alerts are triggered.
Step 4 — Victim Completes MFA, Authenticating the Attacker’s Session
The victim enters their credentials and completes their MFA challenge. This action authorizes the attacker’s backend application, not the victim’s own device.
Step 5 — Attacker Polls the Token Endpoint and Captures Tokens
While the victim authenticates, the attacker’s script continuously polls the `/token` endpoint using the device code. Once the victim completes MFA, the endpoint returns valid OAuth access and refresh tokens, which the attacker immediately captures.
Step 6 — Persistent Access & Lateral Movement
Refresh tokens can be reused indefinitely to generate new access tokens, allowing attackers to maintain persistent access even after password resets.
Technical Walkthrough — Simulating a Device Code Request (for Defensive Testing Only)
Use curl to simulate a device code request (replace client_id with your test app) curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/devicecode \ -H “Content-Type: application/x-www-form-urlencoded” \ -d “client_id=YOUR_CLIENT_ID&scope=https://graph.microsoft.com/.default”
Expected Response (JSON):
{
“device_code”: “DAQMABAAEAB8...“,
“user_code”: “G7X9M-KD4R2”,
“verification_uri”: “https://microsoft.com/devicelogin”,
“expires_in”: 900,
“interval”: 5
}
Disclaimer: Use this only on authorized test tenants.
- Detection Engineering: SIEM Rules, KQL Queries, and Log Analysis
Because device code phishing uses legitimate Microsoft infrastructure, detection must focus on behavioral anomalies in Entra ID sign-in logs rather than traditional indicators of compromise.
Detection Method 1 — Concurrent Sign‑ins with Differing User Agents
Attackers poll the `/token` endpoint using scripts (e.g., Python Requests), while victims authenticate via browsers. Legitimate device code flows typically use the same user agent for both the polling client and the authentication browser.
KQL Query for Microsoft Sentinel:
SigninLogs | where AuthenticationProtocol == “deviceCode” | where TimeGenerated > ago(7d) | summarize UserAgentCount = dcount(UserAgent) by UserPrincipalName, CorrelationId | where UserAgentCount > 1
This query flags sessions where two different user agents (e.g., “Python/3.x” and “Chrome”) are associated with the same authentication event.
Detection Method 2 — First-Time Device Code Authentication by User
Most users never legitimately use device code flow. A first-time event is highly suspicious.
Microsoft 365 Unified Audit Log Query (Search-UnifiedAuditLog):
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -Operations “UserLoggedIn” | Where-Object {$_.AuditData -like ‘DeviceCode’}
Detection Method 3 — Device Registration Immediately After OAuth
If a new device is registered immediately after an OAuth device code sign-in, the attacker is likely establishing persistence.
Detection Method 4 — Unusual Geographic Locations
Cross‑reference the IP geolocation of the device code authentication event with the user’s typical sign‑in location.
- Mitigation: Blocking Device Code Flow via Conditional Access
The most effective mitigation is to disable device code flow entirely unless it is explicitly required for legitimate use cases (e.g., IoT devices, conference room displays).
Step‑by‑Step: Disable Device Code Flow in Microsoft Entra ID
- Navigate to Microsoft Entra admin center → Protection → Conditional Access.
- Click + New policy and name it “Block Device Code Flow”.
- Under Users, select “All users” (or exclude service accounts that legitimately need this flow).
- Under Target resources → Cloud apps, select “All cloud apps”.
- Under Conditions → Authentication flows, check Device code flow.
- Under Access controls → Grant, select Block access.
7. Enable the policy and click Create.
Important: Before blocking globally, audit existing device code sign‑ins to identify any legitimate usage. Use the KQL query from Section 2 to find users who have genuinely used this flow.
If Blocking Is Not Feasible — Restrictive Policy
If device code flow must remain enabled for specific scenarios (e.g., meeting room devices, IoT sensors), restrict it by:
– Limiting to specific trusted IP ranges (e.g., corporate network).
– Limiting to specific device platforms (e.g., Android only).
– Limiting to specific user groups (e.g., service accounts).
4. Incident Response: Token Revocation and Remediation
If a device code phishing attack is suspected or confirmed, immediate token revocation is critical because refresh tokens remain valid even after password resets.
Revoke All Sessions for a User (Microsoft Graph PowerShell):
Connect-MgGraph -Scopes “User.Read.All”, “Directory.ReadWrite.All” Revoke-MgUserSignInSession -UserId “[email protected]”
This command invalidates all active refresh and access tokens for the specified user.
List All OAuth Apps That Have Been Granted Consent:
Get-MgOauth2PermissionGrant -All | Where-Object {$_.ClientId -ne “known_good_client_id”}
Identify and remove any malicious or unrecognized OAuth applications.
Manually Revoke a Specific Refresh Token (Azure CLI):
az rest --method post --url “https://graph.microsoft.com/v1.0/users/[email protected]/revokeSignInSessions”
- EvilTokens & AI-Assisted Phishing: The Industrialization of Device Code Abuse
The recent surge in device code phishing is directly linked to the emergence of EvilTokens, a phishing-as-a-service (PhaaS) platform sold on Telegram that automates the entire attack chain.
Key Capabilities of EvilTokens:
- AI-Generated Social Engineering: Automatically produces convincing phishing emails and landing pages that mimic trusted brands (DocuSign, Microsoft, Mimecast).
- Turnkey Infrastructure: Pre-configured backend systems manage device code generation, victim session tracking, and token harvesting.
- Real-Time Dashboard: Attackers can monitor active campaigns, victim interactions, and successful token captures.
- Railway PaaS Abuse: Threat actors host attack components on Railway’s trusted PaaS infrastructure (valid IP addresses, legitimate domains), allowing the activity to blend in with normal traffic.
Since March 2026, over 50,000 malicious email campaigns have exploited Microsoft’s OAuth device flow.
What Undercode Say:
- Device code phishing is not a vulnerability; it is a design feature turned attack vector. Because Microsoft implements the OAuth device flow exactly as specified by RFC 8628, there is no “patch” for this technique. The only effective defense is administrative control (conditional access blocking) and behavioral detection.
- Refresh token theft changes the incident response game. Traditional password resets are ineffective against this attack. Security teams must integrate token revocation into their playbooks and consider implementing continuous access evaluation (CAE) policies to reduce token lifetimes.
Prediction:
Device code phishing will become the default method for cloud account takeover throughout 2026–2027, surpassing traditional credential harvesting and adversary-in-the-middle (AiTM) attacks. As PhaaS platforms like EvilTokens continue to evolve, we will see commoditized attacks targeting Salesforce, Google Workspace, and other identity providers that support OAuth device flow. Microsoft will likely respond by making device code flow disabled by default for new tenants and by introducing anomaly-based real‑time blocking within Entra ID Protection. Organizations that fail to implement conditional access controls and behavioral detections will face a wave of silent, persistent compromises that bypass all traditional MFA.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecuritynews Gbhackers – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
