What happened?
Microsoft has identified a new wave of phishing and malware campaigns exploiting an OAuth feature to funnel users from trusted login pages into attacker‑controlled sites.
Unlike classic OAuth consent-based phishing techniques, these latest attacks do not try to steal tokens during the login flow, instead choosing to weaponise OAuth’s standards-compliant error handling behaviour to create convincing redirects that appear to originate from legitimate site. This technique is especially dangerous because it abuses trusted platform behaviour - even trained users who check the URLs and links are unlikely to scrutinise dense OAuth query strings or recognise malformed parameters when redirected from a genuine domain first.
The attack chain usually starts with a phishing email, themed around routine business activity as a lure, such as Teams meeting recordings, document reviews or password resets. The link in the email - sometimes embedded in a PDF to evade detection - looks legitimate at a glance; the URL begins with a trusted identity provider domain such as Microsoft or Google, however behind the scenes, the link contains meticulously crafted OAuth parameters that are designed to fail.
The identity provider processes the request, identifies that it cannot succeed, and returns an OAuth error, redirecting the user to the application’s registered redirect URI. Unfortunately, in the case of recent campaigns, the attackers have set this redirect URI to an attacker‑controlled domain, usually resembling a normal login or document page.
The OAuth page’s only role is to give legitimacy and perform the redirect; users are not yet compromised, but the redirect seamlessly transports them into malicious infrastructure.
So what?
Once redirected, two outcomes are likely:
- Phishing / attacker‑in‑the‑middle (AitM) - Victims land on a clone login page, at which point AitM toolkits (such as EvilProxy) intercept credentials, session cookies and MFA responses while passing them through to make the login appear genuine. In this situation, the email address often auto-fills because this data is included in the OAuth state parameter that is passed across.
- Malware delivery - Victims are immediately pushed to a download ZIP files containing LNK shortcuts or HTML‑smuggling loaders automatically. Opening these files can facilitate local reconnaissance or the side‑loading of a malicious DLL, resulting in a connection to remote command‑and‑control servers and established persistence on the infected device through the user of PowerShell commands.
The attacker controls the redirect infrastructure, so they can also change the malicious URI redirected to as needed to evade any countermeasures implemented. They also deliberately engineer the OAuth flow to fail before any real authentication takes place, meaning that protections such as multi‑factor authentication never engage, giving the attacker a viable exploit despite otherwise robust identity safeguards. In addition, users are often bounced between Microsoft domains during sign‑in, so the brief appearance of a genuine URL before the redirect is not unexpected. The combination of these two considerations undermine traditional phishing defences, as the victim believes they are still within a legitimate authentication session.
With stolen credentials, captured session cookies or an infected device, an attacker can move laterally within the environment, allowing them to access cloud resources, exfiltrate data or prepare ransomware deployment.
What should I do?
Microsoft advises that "these campaigns demonstrate that this abuse is operational, not theoretical."
Technical controls should focus on tightening how OAuth applications operate and how redirects are handled within the environment; clear visibility over registered apps, their configured permissions and any unusual redirect activity is essential to reducing exposure. Coupling these measures with robust user awareness and structured monitoring processes helps limit the risk of emerging OAuth‑based redirection attacks.
- Audit any app registrations - enforce allow-listed redirect URIs to reduce the risk of malicious or misconfigured integrations, and regularly audit every OAuth application to confirm its purpose, permissions, and scope, removing anything that is either unused or over‑privileged.
- Hunt for threats – block identified IOCs across any security tools available in your environment.
- Strengthen browser and device protections - configure your endpoint security to detect HTML smuggling, malicious LNK files and DLL side‑loading. Block or scrutinise automatic downloads from unfamiliar domains.
- Enhance identity controls and enable advanced logging - ensure identity provider policies use conditional access and generate alerts to flag anomalous OAuth activity, enabling prompt investigation and containment in the event of an incident. Incorporate any OAuth‑specific logs and anomaly detection into SOC workflows to improve visibility.
- User awareness – remind users that convincing cloned pages can mimic CAPTCHAs, MFA prompts and email autofill; starting on a legitimate Microsoft or Google login page does not guarantee the final destination is safe. Running a phishing simulation that replicates OAuth‑redirect patterns will help validate defences and strengthen user awareness.
- Refine email security policies – phishing emails are the most common initial attack vector for this campaign; ensure that any incoming email policies are configured to hold potential threats for administrative review.