Abuse Open Redirect for Token Stealing and Hybrid Attacks

What this lab covers

You identify how an application handles tokens after authentication, find a redirect it accepts that it should not, and construct a targeted lure that causes a legitimate user's token to be delivered somewhere you control.

From there the lab moves into the environment behind the application, including serverless components and the connections linking the cloud tenant to on-premises systems, which is where hybrid attacks get their reach.

It is rated intermediate and suits application security practitioners and identity engineers. The phishing component is about crafting a believable pretext, not about volume.

How open redirect becomes token theft

OAuth and OpenID Connect return tokens to a redirect address supplied during the flow. The identity provider validates that address against registered values, and applications frequently register broad patterns or carry a secondary redirect parameter that the application itself honors after authentication completes.

That secondary redirect is the weakness. The identity provider's check is satisfied because the registered address was used, and the application then forwards the user, and often the token or code in the URL or fragment, to an address the attacker chose.

The lure matters as much as the flaw. Because the link points at the genuine application on the genuine domain, it survives inspection by users and by many link-scanning controls. The victim authenticates normally to a site they recognize, and the redirect happens afterwards.

How to detect this in your own environment

Monitor for authentication flows with unusual redirect parameters, and review your registered redirect addresses for wildcards or overly broad patterns. Both are inspectable without waiting for an incident.

Watch for tokens being used from infrastructure that does not match the user's session, which is the shared signature of every token theft technique. Session established in one place, used in another.

Treat newly registered lookalike domains and unusual referrer patterns to your authentication endpoints as worth investigating, since the attacker needs somewhere for the token to land.

How to prevent it

Validate redirect targets against an exact allow list rather than a pattern, and do not accept a redirect destination from user input after authentication. This is the actual fix and it lives in the application.

Register precise redirect addresses with the identity provider and avoid wildcards. Broad registration is convenient during development and frequently survives into production.

Deploy phishing-resistant authentication and device compliance conditions, so a stolen token is less useful when replayed from unfamiliar infrastructure. This does not fix the redirect flaw, and it limits what the theft achieves.

Real-world context

Open redirect and redirect validation flaws have appeared in major SaaS and identity platforms, and their impact is consistently higher than the low severity ratings the underlying issue attracts in isolation, precisely because of what OAuth delivers to the redirect target.

The hybrid dimension raises the stakes further. Where a tenant is connected to on-premises infrastructure, token theft in the cloud can lead to access on internal systems, which is the pattern behind several documented ransomware and espionage campaigns that moved in both directions.

The pattern maps to MITRE ATT&CK T1566.002 Spearphishing Link, T1528 Steal Application Access Token and T1550.001 Application Access Token.

Applying this at work

• Audit registered redirect addresses across your application registrations and replace wildcards with exact values.
• Review your applications for redirect parameters honored after authentication, which is where this class of flaw lives.
• Add detection for tokens used from a different network location than the session that created them.
• Move privileged users to phishing-resistant authentication so a stolen token is harder to replay.
• Inventory your hybrid connections and understand what cloud compromise would reach on-premises, and the reverse.

Frequently asked questions

Why is an open redirect more serious with OAuth?

Because the authentication flow delivers a token or code to the redirect target. On an ordinary web page a redirect sends a user somewhere unexpected, whereas in an OAuth flow it can hand over credentials for their session.

Does the phishing link look suspicious?

Not usually. It points at the genuine application on its real domain, and the user authenticates at the real identity provider. The redirect to attacker-controlled infrastructure happens after authentication succeeds.

How should redirect validation be implemented?

Compare the target against an exact allow list rather than a pattern, and never take a post-authentication redirect destination from user input. Wildcard registrations at the identity provider should be replaced with precise values.

Do I need my own Azure account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.