Open Redirect Phishing Chains: Building Credibility Attack Paths
Plenty of writeups already cover open redirects as SSRF trampolines. This one is about the phishing chain: abusing a trusted hostname as the first hop so victims lower their guard before they ever see your lookalike page.
CWE-601 (URL redirection to untrusted site) is the catalog name. Programs still mark bare redirects low. Chains change the conversation.
The credibility problem redirects solve
Cold links to evil.example die in spam filters and human skepticism. Links that start as:
https://login.victim.com/continue?next=https://evil.example/drop
survive copy-paste from “official” emails and chat. The address bar shows the real brand long enough for a click habit to take over. Some clients even prefetch or unfurl the trusted hop, adding legitimacy in previews.
Chain recipes I actually use
Login continue / returnUrl
After password entry or SSO, the app sends the browser to next=. Plant your URL. Pair with a cloned login theme only if the program allows phishing demos against test accounts — never real users.
Multi-hop allowlists
Hop1: victim.com/exit?u=https://victim.com/exit?u=https://evil. Filters that only check the first domain miss the nested jump. Document each hop.
Protocol-relative and encoding theater
//evil.example, \\evil.example, over-encoded slashes, and mixed / \ tricks still appear on older stacks. Show which client follows them (browser vs in-app webview).
OAuth-adjacent confusion
Not a substitute for a real redirect_uri bypass, but a documented open redirect on an allowlisted post-login landing can support token theft narratives when tokens land in query strings. Only claim that with a concrete leak.
Evidence that bumps severity
- Video: click branded link → land on credential harvest page you control
- Show the redirect parameter unauthenticated attackers can mint
- Tie to an email or in-product notification template that already uses the same continue URL pattern
- If the program bans pure phishing, pivot to demonstrable session or token exposure instead
PortSwigger’s open redirection material and CWE-601 help frame remediation: allowlist paths, use relative redirects, or map IDs to server-side destinations.
What I avoid claiming
“Critical account takeover” from a naked redirect with no token, no XSS, and no OAuth break. Triagers have seen that movie.
I treat open redirects as raw material. The phishing chain is how you turn a dull next= parameter into a story security teams recognize from real incident queues.