They Didn't Steal Your Password. They Used the Login Page Against You.

A phishing campaign targeting U.S. government agencies just rewrote the rules. No stolen tokens. No exploited software. No zero-day. The attackers weaponized the login page itself — turning Microsoft's and Google's own authentication infrastructure into a delivery system for malware and session hijacking tools. And the worst part? Every piece of it was technically legal by internet standards.

On March 2, 2026, the Microsoft Defender Security Research Team published a disclosure that should have made headlines everywhere. Quietly, it did not. The report confirmed active, operational phishing campaigns against government and public-sector organizations — campaigns that bypassed email filters, browser reputation engines, and in some cases MFA, without exploiting a single vulnerability in the traditional sense. The source for everything that follows is the original Microsoft Defender Security Research Team advisory published March 2, 2026, with technical context drawn from RFC 6749 (the OAuth 2.0 Authorization Framework) and RFC 9700 (OAuth 2.0 Security Best Current Practice).

The research team named in the advisory includes Jonathan Armer, Fernando Dantes, Sagar Patil, Bharat Vaghela, Krithika Ramakrishnan, Sean Reynolds, and Shivas Raina. These are the people who found it. What they found is worth understanding in depth — because the attack pattern they described is not going away. It is going to be copied.

What OAuth Is (and Why It Was Trusted)

Before understanding how this attack works, you need to understand what OAuth is designed to do. OAuth 2.0 — formalized in RFC 6749, published by the Internet Engineering Task Force in October 2012 — is the authorization framework that powers nearly every "Log In With Google" or "Sign In With Microsoft" button on the internet. It allows a user to prove their identity through a trusted central provider (called an identity provider, or IdP) and then be handed off to an application with a token proving who they are. The application never sees your password. That is the point.

The flow involves a redirect. When you authenticate successfully, the identity provider sends your browser to a registered callback URL — the redirect URI — belonging to the application you are trying to use. This is not a bug. It is the core design. The redirect is how the authenticated session gets back to the requesting application.

But here is the part attackers have weaponized: OAuth also redirects when something goes wrong. When a request fails — due to an invalid scope, an unresolvable user session, or a policy violation — the identity provider still sends the browser somewhere. It sends it to the registered redirect URI on file for the application that made the request. And registered redirect URIs can point anywhere.

"OAuth includes a legitimate feature that allows identity providers to redirect users to a specific landing page under certain conditions, typically in error scenarios or other defined flows. Attackers can abuse this native functionality by crafting URLs with popular identity providers, such as Entra ID or Google Workspace, that use manipulated parameters or associated malicious applications to redirect users to attacker-controlled landing pages." — Microsoft Defender Security Research Team, March 2, 2026 (source)

The key insight here is that the attackers did not need to break OAuth. They needed to register a malicious application — something anyone with a Microsoft or Google account can do — and then craft a request that was designed to fail in a very specific, controlled way.

How the Attack Works: The Five-Stage Chain

The attack Microsoft documented is not a single technique. It is a carefully sequenced chain of five stages, each one building on the last. Understanding all five is what separates a security-aware person from someone who clicks the link.

Stage 1: The Email

Everything starts in the inbox. Threat actors distributed phishing emails themed around topics designed to trigger immediate action: e-signature requests, Social Security notices, Microsoft Teams meeting invitations, financial document alerts, and political themes. Some samples also included fake calendar invite (.ics) attachments to reinforce the appearance of a legitimate meeting or event. These are not generic spam. They are crafted to match the professional context of the targets — people working in government and public-sector organizations who regularly handle these exact types of communications.

The delivery infrastructure was sophisticated. According to the Microsoft advisory, attackers used Python- and Node.js-based mass-sending tools running on cloud-hosted virtual machines. Some campaigns embedded the malicious OAuth URL directly in the email body. Others buried it inside a PDF attachment with no body content at all — a technique that defeats email body scanners by moving the payload to an attachment that appears to be a harmless document.

Stage 2: The Silent Probe

When the victim clicks the link, they are sent to a real Microsoft or Google authentication endpoint — specifically, Microsoft Entra ID's /common/oauth2/v2.0/authorize endpoint. To anyone watching, this looks like a normal login URL. The domain is legitimate. The certificate is valid. There is no red flag in the address bar.

But the URL has been surgically altered. The attackers set two parameters with deliberate intent:

• prompt=none — This tells the identity provider to attempt silent authentication. Do not show the user a login screen. Just use whatever session already exists.
• scope=invalid (or any nonsensical scope value) — This tells the identity provider to request permissions that do not exist. The request is designed to fail. Microsoft Defender's advisory notes that an invalid scope is one method used to trigger the error redirect, but not the only one — errors can also occur when the user is not logged in, when the browser session cannot be retrieved, or when the application lacks a service principal in the user's tenant.

At this point, Entra ID or Google Workspace does something predictable and standards-compliant: it evaluates the request, determines it cannot succeed silently, and prepares to redirect the user back to the registered redirect URI with an error response. That redirect URI was registered by the attacker when they created their malicious OAuth application.

Stage 3: The Redirect

The identity provider has now done the attacker's delivery work for them. The victim's browser is sent from login.microsoftonline.com or accounts.google.com to a domain controlled by the attacker. From the user's perspective, they clicked a link, a Microsoft or Google URL appeared briefly, and then they arrived at a page. The transition felt normal. The trusted domain did the redirecting. It is worth noting that Microsoft Defender's advisory explicitly documents the Google OAuth variant alongside the Entra ID variant: both are actively exploited in this campaign, making this a cross-platform technique rather than a Microsoft-specific exposure.

There is one additional detail that makes this more effective than it sounds. Attackers repurposed the OAuth state parameter — which is supposed to be a random, unpredictable value used to correlate authorization requests and responses — to carry the victim's email address. Microsoft's advisory documented four specific encoding methods observed in the wild: plaintext, hex string, Base64, and custom decoder schemes (for example, mapping 11 = a, 12 = b, and so on). When the victim arrives at the attacker's page, that page reads the state parameter from the URL, decodes it, and auto-populates the email field on the landing page. The victim sees their own email address already filled in. It looks like they were expected. It looks like they belong there.

Stage 4: Credential Theft or Malware

At this point the campaign splits into two branches depending on the attacker's objective.

In the credential theft branch, victims land on a phishing framework such as EvilProxy — a commercial phishing-as-a-service platform that operates as a transparent reverse proxy. We will cover EvilProxy in detail in a later section, but the short version is that it sits between the victim and the real Microsoft login page, forwarding everything in real time and stealing both credentials and active session cookies in the process. Session cookies are the real prize because they allow an attacker to impersonate the victim without needing a password or MFA code.

In the malware delivery branch, the victim's browser automatically downloads a ZIP archive from a path like /download/XXXX on the attacker's server. That ZIP contains LNK files — Windows shortcut files — and HTML smuggling loaders. These are the entry points for the final stage.

Stage 5: Persistence on the Endpoint

Opening one of the LNK files triggers a PowerShell command. That command runs host reconnaissance — ipconfig /all to map network configuration, tasklist to inventory running processes — and then uses the Windows tar utility to extract three additional files: steam_monitor.exe, crashhandler.dll, and crashlog.dat. In parallel, an MSI installer drops a decoy document visible to the victim — something that looks like the file they were promised — designed to occupy the victim's attention while execution continues in the background.

PowerShell then launches steam_monitor.exe, a legitimate Valve Steam application file. (Some third-party coverage of this campaign uses the spelling stream_monitor.exe — this appears to be a transcription variation in secondary reporting; the Microsoft advisory consistently uses steam_monitor.exe.) Alongside it sits the malicious crashhandler.dll. When steam_monitor.exe loads, Windows resolves its DLL dependencies using a default search order that checks the application's local directory before system directories. The attacker's crashhandler.dll is found first. It is loaded by the legitimate Steam process. This technique — DLL sideloading — allows arbitrary malicious code to execute under the cover of a trusted, signed binary. The malicious DLL then decrypts crashlog.dat, executes the final payload entirely in memory, and establishes an outbound command-and-control connection. The endpoint is now compromised. The attacker is inside. Microsoft's advisory noted that post-compromise activity confirmed pre-ransomware staging and hands-on-keyboard activity — meaning human operators were actively working within compromised environments, not simply running automated collection tools.

The RFC Loophole No One Wanted to Talk About

Here is the uncomfortable part that the security community needs to reckon with. This attack is not exploiting a bug. It is exploiting a documented, intentional behavior described in the very RFCs that define how OAuth is supposed to work.

RFC 6749, the foundational OAuth 2.0 specification, defines how authorization errors should be handled. When a request fails, the server redirects the browser to the registered redirect URI and appends error information as query parameters. This is the behavior. It is not ambiguous. It is specified.

RFC 9700, the OAuth 2.0 Security Best Current Practice document published by the IETF, actually acknowledges this risk. Section 4.11.2, titled "Authorization Server as Open Redirector," specifically notes that attackers can deliberately trigger OAuth errors using invalid parameters like scope or prompt=none to force silent error redirects. The warning exists in the standard. It just was not heeded at scale.

"The activity described in this report highlights a class of identity-based threats that abuse OAuth's standard, by-design behavior rather than exploiting software vulnerabilities or stealing credentials. OAuth specifications, including RFC 6749, define how authorization errors are handled through redirects, and RFC 9700 documents security lessons learned from years of real-world deployment." — Microsoft Defender Security Research Team, March 2, 2026 (source)

There is no CVE number assigned to this campaign. There is nothing to patch. The behavior attackers exploited is correct behavior. The only way to reduce the risk is to govern who gets to register OAuth applications and what redirect URIs they are allowed to use — governance, not patching.

This is a meaningful shift in the threat landscape. For years, the response to a new attack was to find the vulnerability and patch it. This attack does not have a vulnerability. It has a design that was abused. Defending against it requires organizational policy decisions, not software updates.

Steam, Crash Handlers, and a C2 Server in Your Inbox

The choice of steam_monitor.exe as the sideloading vehicle is worth examining because it is not accidental. DLL sideloading via Steam binaries is a documented technique. According to HijackLibs, a public database of known DLL hijacking vulnerabilities maintained by the security community, crashhandler.dll is a known sideloading target. The legitimate file belongs to Steam's crash handler library. By placing a malicious version alongside the legitimate steam_monitor.exe binary, attackers exploit Windows' default DLL search order — a behavior that has existed in Windows for decades and cannot simply be turned off without breaking large numbers of legitimate applications.

The technique is tagged in the MITRE ATT&CK framework as T1574.001 — Hijack Execution Flow: DLL Side-Loading. It is not new. What is notable here is the combination: a sophisticated protocol-level redirect chain (the OAuth abuse) feeding directly into a well-understood host-based persistence technique (DLL sideloading). The attacker handled the initial access problem with OAuth cleverness, then fell back on reliable, proven endpoint techniques to establish persistence and command-and-control.

Steam is also not an arbitrary choice from a detection evasion standpoint. The gaming platform's binaries are widely trusted by endpoint security tools. Organizations that explicitly whitelist Steam executables — or simply fail to monitor DLL loads from non-standard directories — will not see the malicious DLL activity as unusual. A Sigma detection rule shared on HijackLibs detects this exact scenario by looking for crashhandler.dll loaded from any path outside of the standard Steam installation directories (C:\Program Files\Steam\ and C:\Program Files (x86)\Steam\).

title: Possible DLL Hijacking of crashhandler.dll
detection:
  selection:
    ImageLoaded: '*\crashhandler.dll'
  filter:
    ImageLoaded:
      - 'c:\program files\Steam\*'
      - 'c:\program files (x86)\Steam\*'
  condition: selection and not filter

If crashhandler.dll loads from anywhere else — a temp folder, a user's Downloads directory, an AppData subfolder — that is your alert. That is the indicator to act on.

EvilProxy: The Franchise Model of Phishing

For campaigns that aimed at credential and session theft rather than direct malware delivery, Microsoft observed victims landing on EvilProxy infrastructure after the OAuth redirect. EvilProxy deserves a direct explanation because its mechanics are what make MFA-bypass phishing viable at scale.

EvilProxy is a phishing-as-a-service platform — a commercial product, available for purchase on dark web marketplaces — that operates as a transparent reverse proxy between the victim and the real authentication service. When a victim is redirected to an EvilProxy-powered page, they see an exact replica of the legitimate login page because EvilProxy is fetching and serving the real content dynamically. The page looks correct because it largely is the real page, passed through an attacker-controlled middleman.

"It uses a reverse proxy to fetch all the legitimate content, which the user expects, including the login page, and it sniffs their traffic as it passes through a proxy. This way they can harvest the actual valid session cookies and bypass the need to authenticate with usernames, passwords or MFA tokens." — Security researcher quoted by BankInfoSecurity (source)

When the victim enters credentials and completes MFA, EvilProxy relays those credentials to the real Microsoft or Google service, receives a valid authenticated session cookie in response, and captures that cookie before it reaches the victim's browser. The victim gets logged in successfully. Everything appears to have worked. But the attacker now holds a live, authenticated session token. They can use it to access the victim's account without credentials and without MFA, because authentication has already happened.

When Resecurity first documented EvilProxy in 2022, the platform was priced at approximately $400 per month with shorter-term access tiers available. Pricing has shifted over time as competition in the PhaaS market has grown, with more recent estimates ranging from $150 to $500 depending on the targeted platform and license duration. EvilProxy targets Microsoft, Google, Apple, GitHub, LinkedIn, and others. According to research by Proofpoint, a single EvilProxy campaign observed between March and June 2023 sent approximately 120,000 phishing emails to hundreds of organizations globally. The platform provides a management portal where operators can monitor campaign traffic, track which victims have been phished, and retrieve harvested credentials and session tokens.

It also implements active countermeasures against security researchers. According to analysis by ANY.RUN, EvilProxy employs browser fingerprinting, IP reputation checks, and filtering to block connections from VPNs, proxies, Tor nodes, virtual machines, and known security research infrastructure. When suspicious activity is detected, EvilProxy can redirect connections to legitimate websites or drop them entirely to avoid analysis. Security tools trying to analyze the phishing pages encounter something completely different from what a real victim would see — which is precisely why traditional automated phishing scanners have difficulty flagging EvilProxy infrastructure.

The pairing of OAuth redirect abuse with EvilProxy at the landing stage is particularly well-designed. The OAuth step handles delivery and bypass of email/browser defenses. EvilProxy handles the actual credential and session interception on the other side. Each component does one job and does it well. The two together form an attack chain with almost no visible seam to catch on the way through.

Why This Campaign Is Different From Everything Before It

There have been many phishing campaigns. This one deserves attention beyond the typical news cycle for a specific reason: it represents a maturation in attacker strategy that mirrors how legitimate security defenses have evolved.

For years, phishing meant fake login pages. The defense was browser reputation engines and email URL scanners that flagged domains that looked suspicious or were newly registered. Attackers responded by compromising legitimate websites to host their pages. The defense got better at detecting compromised infrastructure. Attackers responded by shifting to trusted platforms — open redirectors on legitimate services like job boards and document-sharing platforms — to make the first hop look clean.

Organizations then invested heavily in MFA. Attackers responded with adversary-in-the-middle frameworks like EvilProxy that intercept sessions in real time, making MFA irrelevant to an attacker who can capture the post-authentication cookie. MFA is not useless — it raises the cost of attack significantly — but it is no longer the ceiling it once appeared to be.

Now organizations are strengthening token lifetime policies, deploying Continuous Access Evaluation, and requiring phishing-resistant MFA like FIDO2 passkeys. Attackers have responded again: rather than trying to steal credentials or bypass MFA at all, they are exploiting the authentication protocol itself as a redirect vehicle, skipping the credential theft step entirely and going straight to payload delivery or session capture via a path that identity providers handle automatically.

"As organizations strengthen defenses against credential theft and MFA bypass, attackers increasingly target trust relationships and protocol behavior instead." — Microsoft Defender Security Research Team, March 2, 2026 (source)

This is not a new class of attacker. This is the same class of attacker getting better. The adversaries behind these campaigns are not exploiting software they don't understand — they are reading RFC documents, registering applications through normal developer portals, and building infrastructure that looks identical to what legitimate developers build. There is no technical artifact to seize and no vulnerability to report. The campaign is running on the same infrastructure the internet uses to function.

Microsoft confirmed that several malicious OAuth applications identified during the investigation were disabled by Microsoft Entra — but also confirmed that related OAuth abuse activity continues to be detected. Removing specific applications does not remove the technique. Any actor who reads the Microsoft advisory now knows exactly how to replicate it.

Key Takeaways and What to Do Right Now

1. Restrict who can register OAuth applications in your tenant. The attack chain begins with an attacker registering an application. In many organizations, any user can do this by default. In Microsoft Entra ID, this is controlled under User Settings. Limiting app registration to administrators or approved developers eliminates the entry point entirely for internal tenants. The relevant Microsoft documentation is Configuring User Consent in Entra ID.
2. Audit your existing OAuth application registrations. Pull a full list of registered applications in your Entra ID or Google Workspace admin console. Look for applications with no description, no legitimate owner, recently registered, or with redirect URIs pointing to external domains you don't recognize. Remove anything you cannot account for. Overprivileged apps that have not been used in months are attack surface.
3. Hunt for the specific URL pattern in your logs. Microsoft Defender XDR customers can run queries against UrlClickEvents and DeviceEvents looking for clicks on URLs that include the /oauth2/v2.0/authorize endpoint combined with scope=invalid or prompt=none. Note that the literal string scope=invalid is what Microsoft's published detection query targets — but the broader pattern to hunt for is any OAuth authorization URL arriving via email that uses prompt=none and resolves through a redirect to an external domain. Also look for DeviceFileEvents where the file origin URL contains error=consent_required, which indicates the OAuth error redirect delivered a file download directly.
4. Deploy the Sigma rule for crashhandler.dll and use Microsoft's published KQL query. If you have SIEM or EDR with image load telemetry, the detection rule shared on HijackLibs catches DLL sideloading via Steam binaries by path. Microsoft's Defender XDR advisory also published a production-ready KQL query for DeviceImageLoadEvents that specifically checks for crashhandler.dll loaded by steam_monitor.exe from any path outside of System32, SysWOW64, winsxs, and Program Files — a more precise filter than path-exclusion alone. Before deploying either rule in production, verify it against the current Microsoft advisory, as detection logic may be updated as the campaign evolves.
5. Enforce Continuous Access Evaluation and device-bound tokens. If attackers do obtain a session cookie via EvilProxy or a similar tool, CAE gives you a mechanism to invalidate that session in near-real time when anomalous signals are detected — new IP, new location, impossible travel. Without CAE, a stolen session cookie can be valid for hours or days.
6. Educate users about OAuth redirect lures specifically. General phishing training is no longer enough. Users need to understand that a URL can pass through a legitimate Microsoft or Google domain and still deposit them on a malicious page. The appearance of a trusted domain in the address bar during a redirect is not a guarantee of safety. If a link arrives unsolicited and sends them through a login-looking flow before downloading a file, they should stop and verify through a separate channel.
7. Consider FIDO2 passkeys for high-value accounts. Passkeys are cryptographically bound to the legitimate origin domain. When an EvilProxy or similar reverse proxy intercepts the authentication flow, the passkey will not authenticate against the proxy's domain because it is not the real origin. FIDO2 is currently the strongest available defense against adversary-in-the-middle session capture.

The attackers behind this campaign read the OAuth specification and found a mechanism that works. Defenders need to read it too — and then build governance structures around it that assume bad actors will register applications, craft malformed requests, and exploit the error-handling behavior that the RFC deliberately specifies. The protection is not a patch. It is a policy. And policies only work when someone decides to enforce them.

The Microsoft Defender Security Research Team's full advisory, including detection queries for Defender XDR customers and a complete breakdown of observed indicators of compromise, is available at the Microsoft Security Blog. RFC 6749 and RFC 9700 are publicly available through the IETF Datatracker. The HijackLibs entry for crashhandler.dll including the Sigma detection rule is available at hijacklibs.net.