Active OAuth Redirection Attacks Targeting Government Entities via Entra ID

Microsoft has identified a phishing campaign exploiting OAuth 2.0 flows to deliver multi-stage malware to public sector organizations, successfully bypassing t…

On March 2, 2026, Microsoft disclosed an active phishing and malware delivery campaign leveraging legitimate OAuth 2.0 redirection mechanisms in Entra ID and Google Workspace. The operation specifically targets government and public sector organizations. Rather than stealing tokens or credentials directly, attackers utilize trusted identity provider domains to mask the initial phase of the attack, making detection nearly impossible for standard email and browser filters. This approach turns a perceived secure authentication flow into a silent launcher for multi-stage payloads.

Key Takeaways

Threat actors create malicious OAuth applications within controlled tenants and configure redirect URIs to attacker-owned domains, using crafted parameters like prompt=none and invalid scope values to force redirects without user interaction.
The initial phishing URLs appear benign as they are hosted on legitimate identity provider domains, bypassing reputation-based defenses without the need for traditional OAuth token theft.
Following the redirect, some campaigns automatically distribute ZIP archives containing LNK files that trigger PowerShell scripts for network reconnaissance and extract components including steam_monitor.exe, crashhandler.dll, and crashlog.dat.
The infection chain relies on DLL side-loading: a legitimate executable loads the malicious DLL, which then decrypts crashlog.dat to execute a memory-resident payload and establish C2 connectivity, with observed hands-on-keyboard activity.

Exploiting Redirect URIs: Trusted Domains, Malicious Destinations

According to Microsoft, the campaign relies on the "by-design" exploitation of OAuth 2.0 redirections. Attackers register an OAuth application within a tenant they control and set a redirect_uri pointing to a malicious domain. The initial phishing lures contain links that appear to be standard authentication requests because they are hosted on login.microsoftonline.com or Google Workspace domains.

The requests include specifically crafted parameters: prompt=none prevents the user interface from rendering, while an invalid scope ensures the request fails. Entra ID or Google then returns an error and redirects the browser to the attacker's URI, carrying error parameters that lend a veneer of legitimacy to the transition. The browser executes this redirect silently, landing the victim on a controlled page while maintaining the perception of having interacted with a legitimate service.

From OAuth Error to Payload Delivery

Once the victim reaches the malicious landing page, follow-on activity can trigger without further visible prompts. Certain variants of the campaign automatically deliver a ZIP archive containing a .LNK file designed to mimic a legitimate document or report. Opening this file initiates a sequence executed both in memory and on the local disk.

The LNK file launches PowerShell to conduct network reconnaissance, running commands such as ipconfig and tasklist to map the environment. Simultaneously, the script extracts three files: steam_monitor.exe, crashhandler.dll, and crashlog.dat. The executable is a legitimate binary that, when launched, seeks a specific DLL. The attackers exploit this logic through side-loading: the malicious crashhandler.dll is loaded, which then decrypts the crashlog.dat file and executes the final payload in memory.

"Extraction of the ZIP archive confirmed PowerShell execution, DLL side-loading, and pre-ransom or hands-on-keyboard activity." — Microsoft Security Blog

The payload establishes a connection to an external command-and-control (C2) endpoint. Microsoft reports that in some instances, subsequent activity included hands-on-keyboard maneuvers, suggesting that human operators were directly interacting with the compromised endpoints. The multi-stage nature of this infection makes it difficult for signature-based antivirus solutions to intercept, as individual components may appear benign when analyzed in isolation.

Why Email Filters and Browsers Fail to Detect the Flow

This technique is effective because it exploits an architectural feature of the protocol rather than a software vulnerability that can be patched. The links sent via email are hosted on domains with the highest possible reputation; they are not typosquatted or newly registered domains. Security filters relying on domain reputation or URL blocklists see no reason to flag an address starting with https://login.microsoftonline.com.

The redirection occurs within the error flow rather than through a trivial open redirect or iframe. From the user's perspective, the browser has just contacted Microsoft or Google; the subsequent jump to an unknown domain may go unnoticed or be perceived as a standard part of the authentication workflow. Furthermore, the absence of token theft simplifies the operation: attackers do not need to exfiltrate secrets or maintain persistence within the identity provider; they only need to induce the victim to follow the redirection flow.

Mitigation and Defensive Measures

While Microsoft Entra has disabled the malicious applications observed in this campaign, Microsoft warns that related activities persist and require continuous monitoring. Organizations, particularly those in the government and public sectors, should implement several defensive layers to reduce the attack surface exposed to OAuth redirection abuse.

Audit Redirect URIs: Review every OAuth application registered within Entra ID and Google Workspace tenants to ensure that redirect_uri values point exclusively to known, corporate-controlled domains.
Monitor for Anomalous Parameters: Analyze authentication logs for requests using prompt=none in conjunction with invalid scopes that generate redirect errors, especially those leading to uncatalogued external domains.
Endpoint Inspection: Scan for suspicious LNK files, unauthorized PowerShell processes performing network reconnaissance, and file combinations like steam_monitor.exe paired with unsigned crashhandler.dll files in unusual directories.
Review App Consent Policies: Restrict the ability of standard users to grant consent to unverified OAuth applications and implement policies requiring administrative approval for any new app registrations involving redirection permissions.

While these actions do not eliminate the structural risk of the protocol, they significantly narrow the window for attackers to register malicious apps and reduce the likelihood of a silent redirect leading to a hands-on-keyboard compromise.

Targeting the Public Sector: The Changing Perimeter

The victims identified by Microsoft are predominantly within the government and public sector. This targeting is likely due to the complex, heterogeneous nature of state-owned tenants, which often feature legacy applications and complex authentication workflows with broad or poorly controlled redirect_uri settings. The implicit trust that public sector users place in official links further increases the success rate of these phishing attempts.

The impact is measured by the attackers' ability to transition from an initial click to an interactive session on sensitive endpoints. The OAuth path is no longer just a vector for credential theft but a launcher for remote code execution. This shifts the defensive perimeter from simply blocking suspicious links to monitoring the entire post-redirect execution chain, including the in-memory behavior of processes loaded via side-loading. Endpoint defenses must integrate monitoring for child processes of PowerShell and DLLs loaded by seemingly innocuous executables.

The March 2 campaign demonstrates that trusted protocols can be weaponized for initial intrusion without compromising the provider itself. As long as OAuth redirection remains a legitimate and necessary function, the line between secure authentication and compromise will depend increasingly on granular tenant control and visibility into error logs. For public organizations, the challenge is no longer just educating users not to click, but ensuring that a click on a technically genuine link does not result in a malicious DLL being loaded into memory.

Frequently Asked Questions

Are attackers stealing tokens or credentials with this technique?

No. According to Microsoft’s report, the campaign does not aim to steal OAuth tokens or user credentials. The abuse is limited to redirecting victims to a malicious landing page by exploiting the protocol's error flow.

Why don't email filters block these links?

The initial URLs are hosted on legitimate, high-reputation domains such as those used by Entra ID or Google Workspace. The redirection happens later in the OAuth error flow, bypassing controls that only inspect the initial domain's reputation.

Does the use of steam_monitor.exe indicate a compromise of Steam or Valve?

No. The file is a legitimate component used by attackers merely to mask their DLL side-loading activities. There is no evidence that Valve or the Steam platform have been involved or compromised in this campaign.

Information has been verified against cited sources and is current as of the date of publication.