OAuth Phishing: When the Login Page You Trust Is the Attack
OAuth Phishing – The email looked legitimate. It arrived from a recognised sender, passed authentication checks, and contained nothing obviously suspicious. It invited the recipient to sign a document via a familiar-looking Microsoft or Google login flow — the same screen employees see dozens of times a day. So they clicked. They authenticated. And somewhere in that process, a piece of malware quietly installed itself.
This is the new shape of credential phishing. Not the clumsily worded scam asking you to update your bank details, but a precisely constructed attack that exploits the protocols your organisation already trusts to route victims through legitimate infrastructure on the way to something harmful. The technique is called OAuth redirection abuse, and Microsoft’s Defender research team publicly detailed it on 2 March 2026 after uncovering active campaigns targeting government and public-sector organisations.
OAuth — Open Authorisation — is the standard that lets applications request permission to act on your behalf without ever seeing your password. It’s the mechanism behind every “Sign in with Google” or “Connect with Microsoft” button on the web. It is trusted by design. Attackers have noticed.
What makes this wave of attacks particularly difficult to contain is that it doesn’t rely on fake domains, suspicious attachments, or tell-tale signs of compromise. It weaponises the existing trust relationship between your users, your organisation’s identity infrastructure, and the platforms your business runs on.
What OAuth Redirection Abuse Actually Is — and Why It Works
OAuth’s core design includes a redirect URI: after a user authenticates, the identity provider sends them to a destination URL specified in the application configuration. In a legitimate flow, that destination is the real application. Attackers have found a way to manipulate that destination.
The technique works by registering a malicious application with a legitimate identity provider — Microsoft Entra ID or Google Workspace — and configuring it with a redirect URI that points to attacker-controlled infrastructure. The attacker then sends phishing emails containing links that appear to initiate an ordinary OAuth authentication flow. The user follows the link, lands on a genuine Microsoft or Google sign-in page, and authenticates. But the redirect after authentication doesn’t send them to a legitimate application — it sends them to a malware download or credential-harvesting page.
What makes this so technically elegant — and so dangerous — is that the authentication step itself is entirely real. The identity provider’s login page is genuine. The URL in the browser may show login.microsoftonline.com or accounts.google.com. The SSL certificate is valid. By the time the victim reaches the attacker-controlled destination, they have no reason to be suspicious. Every visual cue that employees have been trained to check as a sign of safety has been satisfied.
The Anatomy of an Attack: From Lure to Malware Payload
Microsoft’s researchers documented the attack chain in careful detail. The campaign begins with a phishing email. The lures used are deliberately mundane: an invitation to view a Teams meeting recording, a request to e-sign a document, a prompt to validate a Microsoft 365 password, a calendar invitation, or — in campaigns targeting government employees specifically — emails referencing social security matters, financial information, or political themes.
The emails are engineered to compel action without raising alarm. They avoid the grammatical errors and implausible urgency that security awareness training has taught employees to spot. Once a user clicks and proceeds through the OAuth flow, they inadvertently download a ZIP archive. When unpacked, the archive triggers a chain of events: a Windows shortcut file executes PowerShell, which performs host reconnaissance and drops an MSI installer. A decoy document is displayed to the victim to maintain the illusion of legitimacy, while in the background a technique called DLL sideloading uses a legitimate binary — steam_monitor.exe — to load a malicious DLL, which decrypts and executes a final payload that establishes command-and-control.
The sophistication here is telling. This isn’t commodity malware distributed via spam — the use of DLL sideloading, encrypted payloads, and reconnaissance scripts suggests an organised threat actor with clear objectives, running a pre-ransom or hands-on-keyboard operation designed for persistence and data access rather than opportunistic credential theft.
Why Traditional Email Security Misses These Attacks
The effectiveness of OAuth redirection abuse is not accidental. It is purpose-built to defeat the assumptions underlying most email security controls.
Traditional email filters look for malicious links and malicious attachments. OAuth phishing emails contain neither. The link in the email points to a legitimate identity provider. The redirect only becomes malicious after authentication — which happens after the email has already been delivered and evaluated. Static analysis at the point of delivery finds nothing to act on. Reputation-based blocklists don’t help when the domains in use are Microsoft’s and Google’s own sign-in infrastructure.
This is precisely why post-delivery protection and click-time URL evaluation have become so critical. An email that looks clean at the gateway may deliver something dangerous at the moment of interaction. Spambrella’s inbound email threat protection includes click-time link evaluation that re-assesses destination URLs at the moment of clicking — not at delivery — which means redirect chains that resolve to malicious infrastructure after authentication can still be intercepted. The attack also underscores the value of sandboxed payload analysis: when a ZIP archive is downloaded post-redirect, an environment that can detonate and examine the contents before execution reaches the endpoint provides a critical last line of defence. Spambrella’s Targeted Attack Protection evaluates attachments and downloaded payloads in exactly this way.
Who Is Being Targeted — and What the Stakes Are
Microsoft identified government and public-sector organisations as the primary targets in the campaigns it tracked. That is consistent with the sophistication of the attack chain and the nature of the payloads being delivered — pre-ransom activity and hands-on-keyboard operations suggest an interest in persistence and data exfiltration, not just quick credential theft.
That said, the technique itself is not inherently limited to government targets. The infrastructure required to execute OAuth redirection abuse is accessible to any threat actor with moderate technical capability. The identity providers — Microsoft Entra ID and Google Workspace — are used by virtually every mid-to-large organisation in the world. The lures — Teams meeting recordings, e-signature requests, M365 password resets — are plausible in almost any organisational context. Expect to see this technique adopted more broadly as the details become common knowledge in the threat actor community.
For organisations running hybrid environments or those that rely heavily on SaaS platforms, the attack surface is particularly broad. Every OAuth application that employees have authorised represents a potential vector if that application’s permissions are excessive or its redirection logic can be manipulated. Many organisations have accumulated dozens or hundreds of third-party OAuth applications over time, many of which are underused, overprivileged, and rarely audited. That is the environment attackers are counting on.
What Organisations Need to Do to Stop OAuth Phishing
The defensive response to OAuth phishing redirection abuse requires action at three layers: application governance, identity controls, and email security.
On the application governance side, Microsoft explicitly recommends limiting user consent permissions. In many Microsoft 365 tenants, users are permitted to grant OAuth consent to third-party applications without administrator approval. Removing that permission — or restricting it to pre-approved publishers — eliminates the path attackers use to register malicious applications in your identity provider. Conduct a periodic review of all OAuth applications that have been granted access to your environment and revoke anything unused or overprivileged.
At the identity layer, Conditional Access policies and multi-factor authentication remain essential, but they need to be supplemented with anomalous application consent monitoring. Microsoft Entra ID provides alerts for unusual consent activity — these should be actively monitored and acted on. The goal is to make the application registration step visible and auditable before an attacker can exploit it. Cross-domain detection that correlates signals across email, identity, and endpoint substantially reduces dwell time when an attack does succeed.
For email security, the attack reinforces the case for protection that operates beyond delivery time. Click-time link evaluation, post-delivery remediation capability, and behavioural analysis that can flag anomalous download activity all play a role. Security awareness training should be updated to include OAuth-specific scenarios — employees who understand that a genuine Microsoft sign-in page can still be part of a phishing attack are significantly harder to deceive than those whose training was written before this technique existed. The traditional heuristic of “check the URL” no longer offers meaningful protection when the URL really does point to Microsoft.
OAuth Redirection Abuse: The Bottom Line
The OAuth phishing redirection abuse technique represents a meaningful evolution in phishing methodology. It doesn’t bypass your email security by sending better malware — it bypasses it by routing victims through infrastructure your organisation has explicitly decided to trust. That changes the threat model in ways that purely perimeter-based defences cannot address.
For organisations, the practical implication is that email security must now account for threat behaviour that happens after delivery and after authentication. The attack chain that Microsoft documented — from a benign-looking OAuth link to a fully deployed malware payload — traverses multiple systems that have individually done nothing wrong. Catching it requires protection that is sceptical of trust at every stage: at the link, at the download, and at execution on the endpoint.
The wider lesson is that legitimate infrastructure has become one of the primary weapons in the modern attacker’s toolkit. Cloud services, identity providers, and authentication protocols are increasingly abused not because they can be compromised, but because they can be exploited. Defending against that demands controls that interrogate behaviour rather than simply verify identity — and organisations that have not yet moved beyond gateway-level email filtering need to do so before this technique reaches its full adoption curve.
Further reading:
Phishing Through the Clouds: How Legitimate Cloud Services Have Become an Attacker’s Gateway
Inbound Email Threat Protection – Malware, Phishing, Whaling, Anti-Impersonation…
