Microsoft says attackers abuse OAuth error redirects to deliver phishing and malware

Threat actors are abusing a legitimate part of OAuth to turn trusted Microsoft login links into phishing and malware delivery paths. In a new report, Microsoft says attackers target government and public-sector organizations with phishing emails that contain OAuth authorization URLs, then force authentication errors that redirect victims to attacker-controlled pages.

The trick does not rely on stealing tokens from the OAuth flow itself. Instead, attackers create malicious OAuth applications in a tenant they control, register a redirect URI that points to their own infrastructure, and then send victims crafted links that look like normal Microsoft Entra ID authorization requests. When the request fails in a specific way, Entra redirects the user to the attacker’s page as part of OAuth’s normal error-handling behavior.

Microsoft says the campaigns used lures such as e-signature requests, Social Security notices, financial and political topics, and other common business themes. Some attackers embedded the OAuth URL in a PDF attachment instead of placing it directly in the email body, which can help the message slip past basic scanning rules.

In some cases, victims landed on phishing pages run through attacker-in-the-middle kits such as EvilProxy. In others, they were redirected to malware-hosting pages that delivered ZIP archives containing malicious shortcut files and HTML smuggling components.

How the attack works

Microsoft says one detail made these phishing pages look more convincing: attackers misused the state parameter to carry the victim’s email address, often in encoded form, so the phishing page could pre-fill the username box. The company observed plaintext, hex, Base64, and custom encoding schemes for this step.

On the malware side, Microsoft says some victims were redirected to a /download path that automatically served a ZIP file. Inside, malicious .LNK files launched PowerShell, performed reconnaissance, and prepared the next stage for DLL side-loading. Microsoft says a malicious crashhandler.dll then decrypted and loaded the final payload from crashlog.dat, while a legitimate stream_monitor.exe displayed a decoy to distract the victim.

Why this matters

This is an identity-based attack that abuses intended OAuth behavior rather than exploiting a software bug. Microsoft says the flow follows the standards that define how authorization errors trigger redirects, which means defenders cannot rely only on traditional “check the destination domain” advice when a link begins on a trusted Microsoft login page.

Microsoft also points to RFC 9700, which warns that attackers can deliberately trigger OAuth errors with invalid parameters such as scope or prompt=none to turn authorization endpoints into open redirectors. In other words, the weakness here is not that OAuth is broken, but that attackers have found a practical way to weaponize a standards-compliant behavior.

What defenders should check now

• Review governance for OAuth applications, especially user consent and redirect URI hygiene.
• Limit overprivileged or unused apps and regularly audit tenant app registrations.
• Enforce Conditional Access and identity protection controls around risky sign-in flows.
• Correlate email, identity, and endpoint alerts instead of investigating them in isolation.
• Hunt for URLs containing invalid scope values or suspicious prompt=none behavior.

Microsoft published advanced hunting guidance for Defender XDR customers, including a query that looks for URL click events involving scope=invalid. The company also says Defender alerts tied to this activity can include suspicious network protection events, unexpected DLL loading, and a “Silent OAuth probe followed by malware delivery attempt” alert.

FAQ