Listen to this Post
Introduction:
OAuth device code flow, designed for input-constrained devices like smart TVs and printers, is increasingly exploited by threat actors to bypass multi-factor authentication (MFA) and traditional static analysis. In a recent campaign documented by Palo Alto Networks Unit 42, attackers shifted from credential theft to device code phishing, using runtime-fetched landing pages and blob URLs to evade detection. This article dissects the technique, provides step‑by‑step adversary simulation, and offers defensive commands and configurations for Linux, Windows, and cloud environments.
Learning Objectives:
- Understand how the OAuth device authorization grant works and why it is vulnerable to phishing.
- Simulate a device code phishing attack using Azure AD or any OAuth 2.0 provider for red teaming purposes.
- Implement detection and mitigation strategies, including conditional access policies, log monitoring, and user training.
You Should Know:
- Anatomy of an OAuth Device Code Phishing Attack
This attack replaces hardcoded malicious URLs with dynamically fetched landing pages and uses blob URLs for in‑memory image generation, evading URL reputation scanners. The attacker tricks the victim into visiting a legitimate Microsoft, Google, or other OAuth login page and entering a device code that the attacker obtained. Once the victim enters the code, the attacker receives an access and refresh token, effectively bypassing MFA.
Step‑by‑step breakdown of the attack flow:
- Step 1: Attacker registers a malicious application with an OAuth provider (e.g., Azure AD).
- Step 2: Attacker initiates the device code flow by sending a POST request to the `/devicecode` endpoint.
- Step 3: The provider returns a
user_code,device_code, andverification_uri. - Step 4: Attacker crafts a phishing email or landing page that mimics a document notification, prompting the victim to visit the legitimate `verification_uri` and enter the
user_code. - Step 5: Victim enters the code on the real login page, completing MFA if required.
- Step 6: Attacker polls the `/token` endpoint with the `device_code` and receives tokens.
Simulation using `curl` (Linux/macOS) against Azure AD:
Request device code curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/devicecode \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=YOUR_MALICIOUS_APP_ID&scope=User.Read Mail.Read" Output includes user_code (e.g., ABC123) and verification_uri (https://microsoft.com/devicelogin) Attacker then polls for token curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=YOUR_MALICIOUS_APP_ID&grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=RETURNED_DEVICE_CODE"
Windows PowerShell equivalent using `Invoke-RestMethod`:
$body = @{client_id="YOUR_APP_ID"; scope="User.Read"} | ConvertTo-Json
Invoke-RestMethod -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/devicecode" -Method Post -Body $body -ContentType "application/x-www-form-urlencoded"
2. Detecting Device Code Phishing with Log Analytics
Adversaries rely on the victim not recognizing the legitimate verification URI. Defenders can monitor for abnormal device code requests, especially those with high polling frequencies or originating from unexpected IPs.
Linux – Using `grep` and `jq` on Azure AD sign‑in logs (exported as JSON):
Extract device code authentication events cat azure_signin_logs.json | jq '.[] | select(.authenticationRequirement == "singleFactorAuthentication" and .status.errorCode == 0 and .authenticationDetails[bash].authenticationMethod == "Device Code")'
Windows – Querying Microsoft Graph API for device code logins:
Requires MSAL.PS or AzureAD module
Connect-AzureAD
Get-AzureADAuditSignInLogs -Top 100 | Where-Object {$<em>.AuthenticationRequirement -eq "singleFactorAuthentication" -and $</em>.ClientAppUsed -eq "Device Code Flow"}
Mitigation: Create a Conditional Access policy in Azure AD that blocks the device code flow for all users except known service principals. Use PowerShell to set authentication context:
New-AzureADPolicy -Definition @('{"AuthenticationFlowsPolicy":"DisableDeviceCode"}') -DisplayName "BlockDeviceCode" -Type "AuthenticationFlowsPolicy"
- Runtime‑Fetched Landing Pages and Blob URLs – Evading Static Analysis
Attackers now load phishing content dynamically using JavaScript that fetches HTML and images from remote sources, generating blob: URLs for images to bypass static scanners. The campaign observed uses an email with a “VIEW/DOWNLOAD” button that triggers a script to fetch a malicious landing page only at runtime.
How to simulate and test this evasion (for blue teams):
– Create a simple HTML page that fetches content via `fetch()` and injects it into the DOM.
– Generate a blob image URL using JavaScript:
fetch('https://attacker.com/phish_image.png')
.then(response => response.blob())
.then(blob => {
const imgURL = URL.createObjectURL(blob);
document.getElementById('phish_img').src = imgURL;
});
– The resulting `blob:https://legit-site.com/…` URL is not blocklisted by most URL filters.
Detection: Monitor network logs for unusual `blob:` URL creations combined with external fetch requests. Use browser security policies (CSP) to restrict `blob:` usage to trusted scripts only.
Linux – Using `tcpdump` to capture suspicious outbound fetches:
sudo tcpdump -i eth0 'tcp port 443 and (host attacker_domain or host cdn_provider)' -vv
Windows – Enable PowerShell script block logging to detect dynamic code injection:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
- Cloud Hardening – Disable Device Code Flow Where Unnecessary
Many OAuth providers allow you to restrict the device code grant. For Azure AD, use the “Authentication flows” policy; for Google Cloud, limit OAuth clients to specific redirect URIs and disable device flow via the GCP console or API.
Step‑by‑step to disable device code flow in Azure AD using Azure Portal:
1. Navigate to Azure AD > Enterprise applications > Conditional Access.
2. Create a new policy named “Block Device Code Flow”.
3. Under “Cloud apps or actions”, include all apps.
4. Under “Conditions” > “Client apps”, select “Mobile apps and desktop clients” and check “Device code flow”.
5. Set “Access controls” > “Block access”.
6. Enable the policy.
Using Azure CLI to list apps using device code grants:
az rest --method get --url "https://graph.microsoft.com/v1.0/applications?$select=id,appId,displayName,requiredResourceAccess" | grep -i "devicecode"
5. User‑Facing Mitigation and Training
Since device code phishing uses legitimate login pages, user education is critical. Teach users to:
– Never enter a device code unless they personally initiated the flow on a device they own.
– Always verify the verification URI matches the exact service (e.g., `https://microsoft.com/devicelogin` is legitimate, but check for typos).
– Report any unexpected “Enter code” prompts.
Simulate a safe training example using a fake OAuth environment (e.g., Keycloak with device flow enabled):
Run Keycloak locally with device flow enabled in standalone.xml Then use the device endpoint to generate a user_code for training curl -X POST http://localhost:8080/realms/demo/protocol/openid-connect/auth/device -d "client_id=trainer" -d "scope=openid" Show users the verification_uri and have them identify suspicious elements
What Undercode Say:
- Key Takeaway 1: OAuth device code flow is not inherently insecure, but its misuse turns legitimate authentication into a phishing vector that bypasses MFA and evades static URL filters.
- Key Takeaway 2: Defenders must shift from relying solely on URL blocklists to behavioral detection – monitoring for device code polling patterns, blob URL creation, and runtime‑fetched content.
Analysis: This campaign represents a maturation in phishing tradecraft. By leveraging standard OAuth flows, attackers avoid hosting fake login pages (often flagged by browsers) and instead abuse trusted domains. The use of runtime‑fetched landing pages and blob URLs defeats most automated static scanners that only analyze initial HTML. Organizations using Microsoft 365, Google Workspace, or any OAuth 2.0 provider are vulnerable. The most effective defenses are (1) disabling device code flow for all users except dedicated service accounts, (2) enabling continuous access evaluation (CAE), and (3) training users to recognize legitimate verification URIs. Red teams should incorporate device code phishing in their exercises to test both technical controls and user awareness.
Prediction:
As traditional credential phishing becomes less effective due to MFA adoption, device code abuse will escalate rapidly. We predict that within 12–18 months, major cloud providers will introduce “device code risk signals” such as geo‑location mismatch between device code request and token redemption, as well as mandatory user‑consent prompts for device code flows. Attackers will counter by automating multi‑region proxies and combining device code phishing with adversary‑in‑the‑middle (AitM) frameworks. Without proactive mitigation – like default‑deny policies for device grants – this technique will become a standard entry vector for ransomware and business email compromise (BEC) campaigns.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Oauth UgcPost – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
