Entra ID OAuth Redirect Abuse Fuels Phishing Attacks

Introduction: why this matters

OAuth links to well-known identity providers (IdPs) like Microsoft Entra ID are often trusted by users and, in some cases, treated more leniently by security controls. Microsoft’s latest research highlights a “by design” OAuth redirection behavior being abused to send users from legitimate login domains to attacker infrastructure—enabling phishing and malware delivery while looking like a normal sign-in flow.

This is particularly relevant for IT admins in government and public-sector organizations, which were specifically targeted in the observed activity.

What’s new / key findings

Microsoft Defender Security Research Team observed phishing-led exploitation of OAuth redirection mechanics across email, identity, and endpoint signals:

• Abuse of silent OAuth flows: Attackers craft OAuth authorization URLs using parameters like prompt=none to attempt a silent authentication check (no UI).
• Intentionally invalid scopes to force an error path: Requests include scope=<invalid_scope> (or other failure triggers) to reliably generate an OAuth error.
• Error-driven redirect to attacker-controlled URI: When the IdP returns an error (for example, interaction_required), the browser is redirected to the app’s registered redirect URI, which the attacker configures to point to phishing pages or malware download sites.
• No token theft required for the redirect: The attacker is not necessarily trying to complete OAuth successfully; the redirect is the main goal.
• State parameter misuse for personalization: The state parameter—meant for request/response correlation—was repurposed to pass the victim’s email address (plaintext, hex, Base64, or custom encoding) so phishing pages can auto-populate identifiers.
• Campaign delivery patterns: Phishing lures included e-signature requests, financial/social security themes, document sharing, Teams/meeting content, and password reset prompts. Some used PDF attachments with embedded links and even .ics calendar invites.
• Downstream tooling: Post-redirect pages frequently used phishing frameworks like EvilProxy (attacker-in-the-middle) designed to capture credentials and session cookies, sometimes adding CAPTCHA/interstitial steps.

Impact on IT administrators and end users

• Higher click-through risk: Links begin on trusted IdP domains (for example, login.microsoftonline.com), increasing user confidence.
• Defense bypass pressure: Traditional URL reputation checks may focus on the initial domain and miss the eventual destination.
• Visibility needs across layers: Microsoft notes Defender correlated signals across email, identity, and endpoint, emphasizing that single-control detection may be insufficient.
• Ongoing threat: Microsoft Entra disabled observed malicious OAuth applications, but related activity persists—monitoring is still required.

Action items / next steps

1. Hunt for suspicious OAuth authorize patterns in logs and proxy telemetry, especially:
   • prompt=none combined with unusual/invalid scope values
   • Frequent OAuth failures followed by redirects to non-corporate domains
   • Use of /common/ in unexpected high-volume phishing contexts
2. Review and restrict app consent and app registrations:
   • Audit newly created apps and redirect URIs for untrusted domains
   • Tighten who can register applications/modify redirect URIs in Entra ID
3. Strengthen phishing protections beyond “trusted domain” checks:
   • Ensure URL detonation/safe-link tooling follows redirects
   • Educate users that “starts at Microsoft sign-in” does not guarantee safety
4. Validate Conditional Access and session controls:
   • Monitor sign-in and OAuth error telemetry for anomalies and targeted user groups
5. Use Defender correlation:
   • Leverage Microsoft Defender for Office 365 + Defender for Identity/Endpoint to correlate email lure, sign-in behavior, and endpoint payload activity.