TL;DR: A novel OAuth redirect abuse technique can be detected by behaviour rather than IOCs, according to Push Security, with a customer true positive arriving months after Microsoft’s initial writeup and after the original indicators had already gone stale. The wider lesson is that browser-based identity abuse requires technique-level hunting, not blocklist maintenance.
At a glance
What this is: This case study shows how OAuth redirect abuse can be used as a durable phishing delivery technique that outlives the initial indicators and still produces detections when behaviour changes are tracked instead of IOCs.
Why it matters: It matters because identity and detection teams need to separate attack technique from campaign noise, especially when trusted login flows and browser behaviour are the real control boundary.
Context
OAuth redirect abuse is a browser-based identity abuse pattern that turns a legitimate authentication flow into a delivery path for phishing or malware. In this case study, Push Security argues that the meaningful unit of defence is the technique, not the original indicators tied to one campaign.
The operational gap is straightforward: IOC blocklists decay quickly, but the underlying browser and OAuth behaviour can stay stable across new lures, domains, and payloads. For IAM, detection engineering, and identity-adjacent security teams, that means the question is whether controls can observe the flow itself, not just its reputation.
Key questions
Q: What breaks when OAuth redirect abuse is defended only with IOC blocklists?
A: IOC-only defence breaks because the campaign-specific domains, client IDs, and payloads can change while the redirect behaviour stays the same. That leaves defenders reacting to stale indicators after the technique has already evolved. Behavioural detections are stronger because they track the repeatable abuse pattern, not the disposable campaign wrapper.
Q: Why do trusted identity provider redirects create phishing risk?
A: Trusted redirects create risk because the first hop inherits the reputation of the identity provider, which can hide the malicious second hop from reputation-based controls. The browser may land on attacker-controlled infrastructure after a standards-compliant OAuth error, so the flow looks legitimate until the user is already in the attacker’s delivery path.
Q: How should security teams detect OAuth redirect abuse in browser-based phishing campaigns?
A: Focus on the sequence, not the indicator. Detect the pattern of an OAuth error, an unexpected redirect destination, and follow-on login or CAPTCHA behaviour. That approach remains useful when domains, client IDs, and payloads change, because it tracks the delivery method rather than a disposable campaign artifact.
Q: What should teams do after a redirect-abuse campaign is identified?
A: Teams should turn the observed technique into a standing hunt and correlate it with browser-side telemetry across the estate. The goal is to catch new variants that reuse the same abuse path, even when the domains and payloads are new. That makes the detection resilient instead of campaign-specific.
Technical breakdown
How OAuth redirect abuse uses a trusted login flow
OAuth redirect abuse relies on standards-compliant behaviour in the authentication flow. An attacker registers an application with a redirect URI that points to attacker infrastructure, then crafts an authorization request that forces an OAuth error. The identity provider handles the request normally and sends the browser to the registered redirect destination, which can make the malicious page inherit the apparent trust of the original login domain. The key point is that the redirect itself is not the compromise. It is the delivery path that gets the user onto attacker-owned infrastructure while keeping the first hop looking legitimate.
Practical implication: watch the redirect behaviour and post-authentication landing page, not only the domain seen at click time.
Why IOC-based filtering misses this technique
This technique defeats many network and reputation controls because the initial URL may begin on a trusted identity provider domain, while the destination can change continuously. Domain blocklists, URL filtering, and signature-based proxy inspection depend on stable indicators such as known-bad domains, script hashes, or fixed payload patterns. Here, those indicators can rotate without changing the underlying abuse pattern. Push Security’s case shows that a later true positive used different lures and different IOCs from the initial Microsoft-documented example, while the technique remained the same. That is why the durable analytic unit is behaviour, not artefact.
Practical implication: build detections around the redirect sequence, not the campaign-specific indicators.
What browser telemetry makes the behaviour huntable
Browser telemetry gives defenders a view of the sequence that follows the OAuth error. In this case, the hunt looked for users who hit an OAuth error page and then landed on a login page, CAPTCHA, or other phishing infrastructure. That sequence is stronger than a generic prompt=none signal, which can be noisy because legitimate applications also use silent authentication. The analysis shows how technique extraction turns a broad intelligence report into a repeatable hunt: identify the behavioural mechanism, define the observable transition, and then compare that pattern against live telemetry across the estate.
Practical implication: use browser-side sequence data to distinguish malicious redirect abuse from ordinary OAuth activity.
Threat narrative
Attacker objective: The attacker wants to deliver victims to a phishing or malware page through a trusted OAuth flow and collect credentials or other access-bearing input.
- Entry occurs when the user clicks a lure that initiates a legitimate-looking OAuth flow on a trusted identity provider domain.
- The attacker forces an OAuth error and uses the registered redirect URI to send the browser to attacker-controlled infrastructure.
- The redirected page leads into phishing, CAPTCHA checks, or a phish kit that can be swapped out without changing the core technique.
- The objective is to harvest credentials or continue the phishing chain through a trusted browser path while evading reputation-based controls.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Technique-level identity abuse outlives campaign-level indicators: OAuth redirect abuse shows why browser-based identity attacks cannot be governed as static IOC problems. The redirect path, not the specific lure, is the repeatable control issue. That shifts the practitioner question from whether a domain is known-bad to whether the authentication flow itself is behaving anomalously.
Behaviour is the durable security object: The same abuse pattern can survive changes in client IDs, redirect targets, lures, and payloads. That is the core governance lesson for identity teams and detection engineers alike: reputation decays faster than technique. Practitioners need hunt logic that survives variant creation, or they will keep rediscovering the same abuse under new packaging.
OAuth redirect abuse sits at the boundary between identity and web security: The flow is an identity protocol, but the exploit surface is browser behaviour and post-authentication navigation. That means IAM teams cannot delegate it entirely to perimeter tooling, and security teams cannot treat it as a pure phishing problem. The practical conclusion is that detection ownership has to span identity telemetry and browser-side observability.
Open redirect trust is the wrong assumption to leave unchallenged: The trusted provider domain in the first hop does not mean the second hop is benign. That assumption is especially brittle in environments where silent authentication, service desk links, and browser-based login flows are normal. The implication is that identity programmes must model redirect pathways as part of the attack surface, not as harmless plumbing.
Redirect-sequence hunting creates a new kind of identity control: Redirect sequence drift is the observable gap where a legitimate authentication error is followed by a suspicious landing page. That concept matters because it names the behavioural boundary defenders can actually measure. Practitioners should treat it as a detection primitive for browser-based identity abuse, not as a one-off investigation pattern.
What this signals
Redirect abuse should be treated as a browser-side identity control problem: The flow succeeds because the first hop is trusted and the second hop is mutable. That means detection strategy has to move closer to the user session, where redirects, landing pages, and post-error behaviour can be observed together.
Technique drift is the real risk in browser-based phishing: A campaign can keep the same abuse path while replacing every visible indicator, which makes stale intelligence a weak foundation for response. Teams that operationalise behaviour-based hunting will have a better chance of catching the next variant before it becomes routine.
Browser observability is now part of identity governance: When authentication flows can be turned into delivery mechanisms, identity teams need some way to distinguish normal OAuth behaviour from malicious redirect sequencing. That pushes the problem beyond phishing awareness and into continuous session-level detection.
For practitioners
- Instrument redirect-sequence detections Track the transition from OAuth error pages to login prompts, CAPTCHA gates, or unfamiliar landing pages so behaviour, not domain reputation, drives alerting.
- Separate silent-auth noise from malicious redirects Treat prompt=none and other silent authentication events as baseline noise unless they are paired with an abnormal post-error landing sequence.
- Promote behaviour-based hunts to live queries Convert one-off threat intelligence into standing hunts that look for the same redirect pattern across new lures, domains, and phish kits.
- Correlate browser telemetry with identity flow context Use the browser path, redirect parameters, and post-authentication page behaviour together so investigators can see the technique even when IOCs have rotated.
Key takeaways
- OAuth redirect abuse is durable because the technique survives even when the lure, domain, and payload change.
- The article shows that a later customer detection occurred after the original indicators had already gone stale.
- Behaviour-based hunts that watch the redirect sequence are more resilient than IOC maintenance for browser-based identity abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | OAuth redirect abuse exploits a standards-based authentication flow as a delivery path. |
| Recommendation — Audit redirect handling in authentication flows and block unsafe consumption paths that enable malicious delivery. | ||
| MITRE ATT&CK | TA0001;TA0006 — Initial Access; Credential Access | The technique uses a trusted redirect to reach the victim and then seeks credentials through phishing. |
| Recommendation — Map redirect-abuse detections to Initial Access and Credential Access, then hunt for the follow-on credential collection stage. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potentially adverse events | The article is about monitoring browser and identity flow behaviour for malicious redirects. |
| Recommendation — Monitor identity and browser flows for anomalous redirect sequences that indicate adversarial activity. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The abuse occurs inside OAuth redirect handling and authentication flow behaviour. |
| Recommendation — Review OAuth and OIDC implementations for redirect handling that can be repurposed into phishing delivery. | ||
Key terms
- OAuth Redirect Abuse: OAuth redirect abuse occurs when an attacker manipulates an authentication or consent flow so the user is sent to an attacker-controlled destination. The technique exploits trust in federated login journeys and can be used to stage malware, capture tokens, or disguise malicious delivery.
- Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.
- Technique-Level Hunting: Threat hunting that abstracts from specific campaign details and looks for the underlying method an attacker uses. This is more durable than indicator searching because it follows the attack pattern across different lures, payloads, and infrastructure choices.
- Redirect Sequence Drift: A change in the path a browser follows after an authentication error, especially when a legitimate identity flow is followed by an unexpected landing page. For identity defenders, it is a useful signal because the sequence can be observed even when the visible indicators change.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 31, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org