OAuth's trap: when a legitimate redirection becomes phishing, malware and credentials theft

Microsoft published this week an alert that should put public sector administrators and users on guard: attackers are taking advantage of legitimate OAuth flow redirection mechanisms to bring victims to criminal-controlled infrastructure, thus avoiding many of the usual mail and browser protections. It is not so much a question of violating a service as of exploiting the behavior provided for by the standard of authorisation so that an apparently inoculated URL ends up in a trap.

OAuth is the technical piece that allows applications to ask permission to act on behalf of a user without requiring your password, and is the basis of the login "Login with Google" or "Login with Microsoft." The specification provides that, in certain scenarios (e.g. specific errors or flows), the identity provider redirects the user to a given URL. The attackers have designed malicious applications and links that abuse this redirection to direct the user to pages hosted by the criminals themselves. If you want to review the operation of the protocol, the basic explanation is in oauth.net and the specific documentation of suppliers such as Google and Microsoft details how redirection URI are managed on their platforms ( Google OAuth, Microsoft Enter / Identity).

The mode of operation described by Microsoft combines social engineering and abuse of the OAuth flow: attackers create an application in a tenant that they control and put as URI of redirection a malicious domain. Then they send phishing links in post - with carefully developed lures such as electronic signature requests, Teams recordings or financial and administrative issues - that ask the user to authenticate with the malicious application, often using an intentionally invalid "scope" to force the desired error / redirection route. The result is not always the direct theft of tokens; in several campaigns the purpose was to force downloads that infected the user's own team.

In the cases analyzed, the file that ends up coming to the device is usually a ZIP that contains a direct access to Windows (LNK). When you open that direct access, a PowerShell command is immediately run that inspects the equipment and removes an MSI installer. That installer leaves a decoy document in sight while, behind the scene, it sideloadea a malicious library (a DLL name like "crashhandler.dll") taking advantage of a legitimate binary to load it, disfigure an additional file and release the final load into memory. From there the malware establishes communication with a command and control server to continue the intrusion, which can end up in pre-ransom activity or manual actions by human operators.

In addition to the campaigns that deliver malware, the same redirection technique has been used for pages that implement adverse-in- the-middle type phishing kits (AitM). These frameworks allow you to capture credentials, session cookies or even exchange OAuth codes in real time; known frameworks in the security community have demonstrated the effectiveness of these approaches when the user trusts the flow and the identity provider never blocks the redirection.

Another relevant detail detected by Microsoft is the creative use of the "state" parameter: originally designed to correlate requests and answers and protect against CSRF, in these chains the attackers encode the target's email address to automatically appear on the phishing page, increasing their credibility. It is a reminder that a piece designed for safety can be reused perverse if its content is not verified.

Microsoft has already removed several identified malicious applications, but the conclusion for security equipment and IT responsible is clear: technical controls must be combined with good administrative practices. Limit the consent that users can give to third-party applications, regularly audit the permits granted and revoke unnecessary or overprivileged applications They're critical steps. Microsoft offers application management tools and consent policies on its platform; reviewing these options can reduce the attack surface ( application management in Azure AD / Entre).

To complement these measures, it is appropriate to strengthen protections in endpoints and mail: to prevent the automatic opening of dangerous attachments, to block malicious known domains and files on the link and mail door, and to maintain detection solutions capable of identifying techniques such as PowerShell execution from LNK or DLL sideloading. It is also important to teach users and equipment to suspect links even when they appear to originate from a legitimate supplier; the US Security Agency. The United States and other entities issue practical recommendations against phishing that can be incorporated into awareness-raising programmes ( CISA - Phishing guidance).

In addition, organizations with a central identity should assess more stringent policies: preventing the consent of non-management users for certain applications, requiring administrative reviews for particularly sensitive permits and activating conditional controls that require additional verification or blocking access from unreliable environments. Suppliers' native tools allow for the creation of allowed or denied lists of applications and the monitoring of unusual consent attempts.

This episode recalls that security in the age of identity as a perimeter is multidimensional: it is not enough to protect the perimeter infrastructure if the authorization model itself can be socially manipulated. Prevention requires coordination of identity policies, mail and endpoint controls, and continuous training of people so they're not the weakest link.

If you want to review Microsoft's technical report with all the indicators and examples shown by the Defense team, it is available on your security blog: Microsoft Security Blog - OAuth redirection abuse. To deepen how redirections and URis are managed in different suppliers, official Google and Microsoft documentation on OAuth / Identity is a good starting point ( Google, Microsoft Come in.), and to understand the design of the protocol itself, the reference in oauth.net It's useful.

In short, it is not just a technical issue, but a matter of governance and culture. Maintaining an inventory of applications, limiting what users can actively authorize and reviewing permits are measures that, combined with technical controls, make it difficult for attacks like this to reach a good port.