Join our Newsletter — 33% off our NHI Course

How do attackers use open redirect phishing?

Attackers use open redirect phishing by abusing a trusted site’s redirect feature to send victims through a legitimate domain before landing on a malicious page. The trusted hop can defeat user suspicion and some filters. Defenders should review redirect parameters, restrict unsafe redirects, and monitor for links that chain from reputable domains to external credential theft sites.

How open redirect phishing works in practice

open redirect phishing succeeds because the first click lands on a domain the victim already trusts. The redirect is usually hidden inside an otherwise legitimate URL, so the user sees a reputable brand before being handed off to a credential-harvesting page, fake login, or malware delivery site. That extra trusted hop is often enough to lower suspicion and bypass simple reputation checks.

Attackers favour this pattern because it lets them borrow the credibility of a real domain without compromising the target site itself. The malicious part may appear only after several redirects, which makes the chain harder to inspect manually and easier to camouflage inside email, chat, ads, or shortened links. The technique is especially effective when the final destination imitates a login flow or support workflow.

open redirect abuse also works as a delivery mechanism for broader phishing campaigns, not just one-off lures. A trusted intermediate hop can help attackers rotate URLs, evade URL filters, and reuse the same malicious landing page across different campaigns. NHIMG’s Phishing Guide covers how open redirects fit into the wider set of phishing techniques and detection patterns.

Why redirects are attractive to attackers

The key advantage is trust transfer. People and some controls often treat a reputable domain as a sign that the link is safe, even though the redirect target is attacker-controlled. That means the exploit is less about technical compromise of the trusted site and more about abusing an accepted navigation path that defenders may not scrutinise closely enough.

Open redirects also support scale. A single redirector can be reused across many lures, campaign themes, and final destinations. Attackers can swap the final URL quickly, which keeps the initial link stable while changing the payload behind it. In practice, this makes containment slower because defenders have to trace the full chain, not just the first hop.

When the redirect is embedded in a common business workflow, such as account recovery, document access, or partner portals, the phishing page can look more legitimate than a direct external link. The technique is part of a broader pattern of trusted-site abuse, which NHIMG’s Top 10 Phishing Techniques discusses alongside other user-trust exploitation methods.

What defenders should watch and harden

The practical defence is to treat redirect parameters as attack surface. Unvalidated or overly permissive redirects should be restricted to approved destinations, and links that chain from a trusted brand to an unrelated external site deserve closer inspection. Monitoring should focus on unusual redirect patterns, especially where the final hop is a credential page, a new domain, or a site with poor reputation.

For organisations that expose redirect endpoints, the safest approach is to allow only known internal destinations or tightly controlled allowlists. If a redirect must remain flexible, log the source, destination, and user agent so suspicious chains can be investigated after the fact. That evidence matters when the redirect was used as the first step in a phishing incident rather than as the direct compromise point.

Open redirect abuse often overlaps with other web application weaknesses, so it is worth checking whether the redirect logic is part of a larger input-validation problem. NHIMG’s Web Application Attacks Guide is useful for understanding how unvalidated redirects sit alongside SSRF, CSRF, and other request-manipulation patterns.

Risk and Threat Considerations

Open redirect phishing increases the chance that a user, mailbox filter, or browser will trust a malicious link long enough for the attacker to capture credentials or push a secondary payload. The security issue is not the redirect itself, but the way it launders reputation through a legitimate domain before handing control to the attacker.

Failure mechanism: The attacker exploits an open redirect endpoint to create a link chain that appears benign at the point of click, then swaps trust for a malicious final destination that can steal credentials or deliver malware.

Impact: Successful abuse can lead to account takeover, credential theft, session capture, and broader phishing campaign reach because the trusted hop makes malicious links harder to spot and sometimes harder to block.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK T1566 — Phishing Open redirect phishing is a phishing delivery pattern that abuses trusted links.
Recommendation — Map redirect-based lures to T1566 and hunt for trusted-link abuse in email and web logs.
OWASP ASVS V13 — Configuration Redirect handling is a configuration/input-validation problem in web applications.
V4 — API and Web Service Redirect endpoints are often exposed through web services and application routes.
Recommendation — Restrict redirect destinations and validate parameters before issuing any redirect response. Apply strict input validation and access rules to any endpoint that accepts redirect targets.
CIS Controls v8 CIS-8 — Audit Log Management Redirect abuse is best detected through logging of sources, destinations, and chains.
CIS-16 — Application Software Security Open redirect weaknesses are application flaws that should be identified and fixed.
Recommendation — Log redirect source, target, and outcome so suspicious chains can be investigated. Review application code and route handling for unvalidated redirect behavior.

Practitioner Guidance

What to verify: Check every externally reachable redirect parameter, confirm whether destinations are allowlisted, and test whether the application blocks scheme changes, external hosts, and nested redirect chains. If a redirect can reach a login or token-bearing page, treat it as high priority for review.

Decision rule: If the redirect is needed only for convenience, remove or narrow it. If it is business-critical, constrain it to approved destinations and log the full redirect chain so suspicious use can be reconstructed during incident response.

Practitioner takeaway: Open redirect phishing is effective because it converts a trusted domain into a credibility bridge, so the best defence is to reduce where redirects can go and to detect when a trusted hop ends at an untrusted identity or payment flow.