The OAuth redirection scam that steals credentials

Microsoft security researchers recently alerted about a technique that is taking advantage of a legitimate function of the identity ecosystem to collate malicious pages without resorting to the classic direct supplanting deception. Instead of falsifying or masking domains, attackers are exploiting OAuth's redirection mechanism to "force" the browser or mail client to take the user to a resource controlled by the attacker. The result is a much more difficult phishing scam to detect by automatic filters and by simple visual inspection.

The vector described by analysts combines urgent messages - electronic signature requests, social insurance notices, invitations to meetings or password reinitials - with links that appear to be legitimate authorization requests. Sometimes those malicious URLs are hidden inside PDF files to avoid mail controls. When the victim clicks, the chain of events takes advantage of how identity providers handle authorization errors to redirect the user to an URI that the attackers have registered in OAuth applications under their control. The technical report can be read in the note published by Microsoft: Microsoft Security Blog.

To understand why this trick works it is necessary to remember that OAuth is a standard designed to delegate permissions between services. An identity provider - like Microsoft Enter ID - allows registered applications to request access on behalf of users following very specific rules ( RFC 6749). When something goes wrong during the negotiation - for example, parameters that call for a "silent" authentication (prompt = none) or an invalid scope - the specification provides that the identity service generates an error and, in many cases, responds with a redirection to the URI recorded by the application. The attackers have learned to deliberately provoke this behavior to turn an error response into a route to their own infrastructure.

In practice, abusers create OAuth applications in a tenant that control and record a redirection that points to their server. They then build authorization links that seem legitimate and distribute them in targeted campaigns, especially against public agencies and government entities. When the identity provider detects the intentional "error," it sends the user exactly to the address the attacker set up. In some cases that page is a phishing site that reproduces the login interface; in others, redirection points to a resource that automatically delivers a ZIP with shortcuts (.LNK) and HTML smuggling techniques to remove detections and run code on the victim's team.

Researchers also describe variants in which criminals use man-attack frameworks in specialized means to intercept credentials or session tokens and thus avoid barriers such as multifactor authentication. Tools of this type - for example, known open source projects that facilitate proxy attacks on web sessions - allow an attacker to capture valid cookies or tokens and reuse them before the victim notices something strange; a technical reference of similar projects is available in the Evilginx2 repository: Evilginx2 (GitHub).

A particularly effective detail in these campaigns is the abuse of OAuth's "state" parameter. It is usually used to maintain context between the request and the authorization response; the attackers use it to insert the victim's mail address on the phishing page, which increases the feeling of authenticity and reduces suspicions by seeing their own mail already filled in. In other variants, shortcut opening .LNK executes PowerShell that performs local recognition and triggers a side load chain of DLL: a legitimate binary loads a malicious DLL that decouples and executes the final payload in memory, a pattern known and documented by the threat detection community (see related techniques in MITRE: PowerShell, DLL Side-Loading).

The key to this campaign is not a vulnerability in OAuth, but the use of a standard-based behavior: identity providers are responding exactly as they should to certain errors, and attackers are manipulating those errors in their favour. This is why the defences purely based on URL lists or mail heuristics can fail if a legitimate authorization request - apparently - serves as a cover.

What can organizations do to reduce this risk? Microsoft recommendations point to several complementary directions: limiting who can register applications in the tenant, requiring administrative consent for sensitive permissions, applying sound identity policies and Conditional Access, and coordinating detection between mail, identity services and endpoints to identify cross-domain patterns. The official documentation on permits and consent and on policies of Conditional Access helps to understand how to apply these controls in Azure environments: Permissions and consent in Azure AD and Guide to Conditional Access. It is also good practice to restrict the registration of applications through policies and to regularly audit applications with delegated permits.

At the end-user level, caution should be increased with unexpected links, even when they come from legitimate services or when the message appears to be directed: the attached files containing URLs, such as PDFs, are a regular avoidance technique. The combination of education, advanced mail filters, endpoints behavior analysis and rigorous identity configuration is the best defense. For those who want to deepen how OAuth authorizations work and how to avoid misuse, the application registration process on Microsoft's identity platform provides a useful technical basis: Register apps in Microsoft identity platform.

In short, we face attacks that do not break cryptography or exploit traditional failures, but take advantage of standard behaviors and human chains of trust. The remedy is to recognize that the attack area now includes the authorization infrastructure itself and to apply identity governance controls with the same care as the network and endpoint are protected. As always, security is a coordination between technology, processes and awareness.