This attack has a detail that keeps bothering me. When a victim clicks the phishing link, their browser momentarily visits login.microsoftonline.com, one of Microsoft’s own servers, before discreetly dropping them onto a page that is under the control of criminals. It only takes a few seconds to complete the handoff. Nothing out of the ordinary is visible to the user. When a trusted Microsoft domain is detected, the email security gateway allows it to pass. The attacker has achieved their goal in an instant.
Science fiction is not what this is. Microsoft Defender researchers have been monitoring a number of phishing campaigns since at least the beginning of 2026. These campaigns take advantage of a legitimate OAuth authentication protocol feature, which is the redirect mechanism that kicks in when an authorization request fails. Attackers are purposefully creating URLs that are meant to fail. They want the mistake. The weapon is the mistake.
Knowing what OAuth is meant to do is helpful in understanding why this works. Every time you click “Sign in with Google” or “Connect your Microsoft account,” this protocol quietly operates in the background. It controls permissions, issues tokens, and facilitates the handshake between identity providers and apps. When something goes wrong during the authentication process, one of its built-in behaviors is to reroute users to a specific landing page. That is a feature rather than a weakness. Simply put, attackers have figured out how to direct that redirect toward themselves.
The mechanics are intentional. Within a Microsoft Entra ID tenant under their control, a threat actor registers an application. They designate a domain they own as the redirect destination. Next, they create an authorization URL by combining a parameter called prompt=none, which tells the system to try silent authentication without displaying a login screen, with an invalid permission scope, a scope they know will fail. The request is rejected almost immediately. The error occurs. The redirect is followed by the user’s browser. Even though Microsoft’s infrastructure was only involved for a few milliseconds, every automated security layer between the attacker and the inbox saw the URL as clean.
Different things end up on the other side. Certain campaigns use EvilProxy, a toolkit that sits between a user and a genuine login page in order to intercept credentials and session cookies. Others use a DLL side-loading chain to install persistent access without displaying any overt infection symptoms. Although public-sector organizations and government agencies have been the main targets thus far, the method itself is indiscriminate.
Because it operates differently and is somewhat more unsettling, the device code flow variant is worth discussing separately. Instead of posing as a login page, attackers direct victims to the actual Microsoft verification portal, microsoft.com/devicelogin, and give them a code to enter. The user may even finish their typical MFA challenge in addition to seeing a legitimate SSL certificate and proper branding. Everything appears authentic because it is.
They have just given an attacker persistent OAuth tokens that allow access to their Teams messages, OneDrive files, and Outlook inbox when they click approve. No password was taken. No phony page. Just a feature that was used exactly as intended, but by someone for whom it wasn’t intended.
Last year, Proofpoint researchers showed how an attacker can create internal OAuth applications with custom permissions once they have initial access to a cloud account. These applications continue to have access even after the victim resets their password. The OAuth application continues to function even after you change your password, activate MFA, and take all necessary precautions after finding a breach. It’s a backdoor that is unaffected by the lock you recently changed.
The particular malicious OAuth apps that their researchers found were disabled by Microsoft. That’s important, but it’s not a fix. A patch cannot eliminate the underlying technique, which involves abusing the error-handling behavior of a protocol that is used by hundreds of millions of people on a daily basis, without compromising the protocol itself. Organizations can monitor sign-in logs for DeviceCodeSignIn events, train security teams to flag emails containing OAuth URLs that redirect through third-party infrastructure, and disable device code flow in Entra ID Conditional Access if their employees don’t need it.
It’s difficult to ignore how deftly this attack takes advantage of trust. Human trust, not technical trust. Reasonably, people’s trust in Microsoft’s authentication pages has grown over years of safe use. By pretending to be trustworthy, attackers did not undermine that trust. It was borrowed by them. That’s a more difficult issue than a server that isn’t configured correctly, and it probably needs more attention than it is receiving right now.
