OAuth Redirection Abuse: Weaponizing Trusted Domains for Government-Targeted Phishing

In a recent technical report, Microsoft analyzed active phishing campaigns that abuse legitimate OAuth redirection mechanisms to target government and public sector organizations.

Attackers are not stealing access tokens in these instances. According to Microsoft's observations, they are instead exploiting the by-design error flows of Entra ID and Google Workspace to redirect victims toward malicious pages. This marks the beginning of a multi-stage payload delivery that ultimately leads to endpoint compromise.

The paradox of this initial phase is that the phishing links appear to be hosted on authentic, high-reputation domains. By leveraging the protocol's built-in redirection, attackers transform a legitimate endpoint into a bridge to malicious infrastructure, effectively bypassing traditional reputation-based anti-phishing filters.

Weaponizing the Error Flow: Turning OAuth into a Malware Conduit

Microsoft observed attacks involving the registration of OAuth applications within attacker-controlled tenants, configured with redirect URIs pointing to malicious domains. The phishing links distributed via email adopt institutional themes—such as electronic signature requests, social security, finance, and policy updates—increasing the likelihood of interaction by public sector employees.

According to the analysis, the core of the abuse lies in the manipulation of OAuth 2.0 authorization endpoint parameters. In the observed samples, attackers insert prompt=none and an intentionally invalid scope to force the identity provider to evaluate the user's session state without displaying a graphical interface. If the session is invalid or the scope is incorrect, the provider returns a silent error but still executes the redirect to the attacker-controlled URI. Legitimate authentication thus becomes an invisible tunnel to malicious infrastructure.

Microsoft reports that, in this scenario, Entra ID error code 65001 confirms that consent was not granted and that the access token is neither issued nor stolen. However, the redirection occurs regardless, allowing the attacker to receive the request and proceed with the compromise. Furthermore, the state parameter is often repurposed to carry the victim's email address—using encoding techniques—to the malicious landing page, where the attacker's server can profile the target before serving the payload.

This abuse is not limited to Microsoft Entra ID. The report notes that the analyzed error flow is part of the OAuth 2.0 standard and is equally applicable to Google Workspace, expanding the risk surface beyond the Azure ecosystem.

From Click to C2: The Multi-Stage Payload Chain

Once redirected, the user lands on a page that triggers the automatic download of a ZIP archive. Extraction reveals malicious LNK shortcuts and a loader based on HTML smuggling—techniques designed to evade perimeter security controls and execute initial code on the workstation. The choice of compressed formats and shortcuts exploits user familiarity with document attachments to mask the execution of malicious commands.

Executing the shortcut triggers a PowerShell script dedicated to local system reconnaissance. Subsequently, the payload launches steam_monitor.exe, a legitimate executable used for the side-loading of crashhandler.dll, an altered system library that serves as the vehicle for the final stage code.

The side-loaded DLL decodes the contents of crashlog.dat, a data file hiding the actual payload, and establishes a connection to an external command-and-control (C2) server. During this phase, researchers detected pre-ransomware or hands-on-keyboard activity, indicating the ultimate goal included preparing the ground for subsequent intrusive actions. The modular nature of the chain suggests attackers can adapt the final payload based on the victim's profile and their position within the institutional network.

"The activity targets government and public-sector organizations and uses silent OAuth authentication flows and intentionally invalid scopes to redirect victims to attacker-controlled infrastructure without stealing tokens." — Microsoft Security Blog

The Failure of Reputation-Based Security Filters

Traditional defense systems rely heavily on domain reputation to block phishing. When the original link resides on login.microsoftonline.com or a similar Google endpoint, enterprise filters, browsers, and users tend to view it as inherently secure, creating a logical gap that blacklists cannot easily close.

The issue is compounded by the fact that the attack does not involve token theft. Consequently, authentication anomaly detection systems do not register illicit logins or suspicious session changes, leaving the follow-on compromise without the indicators of compromise (IoCs) that typically help security teams react quickly. The absence of a stolen token also renders post-authentication checks based on geolocation or access velocity ineffective.

Some actors have also utilized free, pre-packaged tools and custom solutions developed in Python or Node.js for bulk emailing, leveraging a commoditization of offensive infrastructure that reduces the time between OAuth app registration and the victim's first click.

From a threat intelligence perspective, the significance of the Microsoft report lies in demonstrating how a standard protocol can be converted into a malware distribution channel without any zero-day vulnerabilities, shifting the defensive burden from domain reputation to flow inspection.

Strategic Defenses and Mitigation

Defensive responses cannot be limited to updating antimalware signatures or user awareness regarding suspicious links, as the originating domain is authentic and the flow appears compliant. Organizations must shift control from the domain to the flow itself, monitoring specific behavioral parameters and adopting a more granular reading of authentication events.

Monitor Redirect URIs: Review OAuth applications registered within corporate and government tenants, ensuring they point exclusively to organization-owned domains and immediately revoking anomalous configurations.

Inspect Authentication Logs: Search for requests combining prompt=none with invalid or unrecognized scopes, as this parameter pairing is the most reliable indicator of an attempt to force a silent redirect.

Implement Behavioral Controls: Configure browsers and corporate proxies to block or alert on automatic ZIP archive downloads triggered immediately after accessing authentication pages, regardless of the top-level domain's reputation.

Network Segmentation: Limit the privileges of workstations in the public sector that handle institutional data to mitigate the impact of a follow-on compromise if the multi-stage payload succeeds in executing PowerShell reconnaissance or establishing a C2 connection.

The takeaway is that blind trust in major identity providers can no longer substitute for full-flow verification. When legitimate infrastructure becomes an invisible bridge for malware, security must move from domain-centric to behavior-centric models. Every redirect warrants a level of scrutiny that few current systems are equipped to provide. In the public sector, where the attack surface is vast and resources are often constrained, these findings serve as a critical alarm.

Frequently Asked Questions

If the link originates from Microsoft or Google, how can the danger be identified? It is impossible to rely solely on the domain. The most concrete indicator is the presence of parameters like prompt=none paired with invalid scopes, followed by a final redirect to an address outside the identity provider’s ecosystem.

Does Entra ID error 65001 mean the attack failed? No. While code 65001 confirms that consent was not granted and no token was stolen, the redirection to the attacker-controlled URI still occurs. The attacker's objective for the redirect phase is achieved.

Is the confirmed payload ransomware? Microsoft describes it as pre-ransomware or hands-on-keyboard activity—preparatory stages following the initial compromise. The distribution of actual ransomware during the observed campaigns has not been confirmed.

Information has been verified against the sources cited in the Microsoft technical report and is current as of the time of publication.

Sources

• Microsoft Security Blog: OAuth redirection abuse enables phishing malware delivery