Category: Deception & Impersonation
Malicious redirects in the browser
Malicious redirects send users through a chain of sites to hide the final destination—often ending in phishing, scams, or malware downloads.
Quick answer
Redirect chains make it harder for filters, users, and logs to see where a click ultimately landed—and attackers can swap the final payload quickly.
For risky links and login flows, isolation keeps the page off the endpoint by running it in a disposable container and streaming only the rendered output to the user.
When you need this
- You’ve seen indicators of this threat in your environment.
- Users frequently click unknown links as part of daily work.
- You need a control that reduces risk without relying on perfect user judgment.
Last updated
2026-01-29
How it usually happens in the browser
- A user clicks a link or ad that goes to a benign-looking redirector.
- The browser is bounced through multiple domains, often with tracking parameters and short-lived URLs.
- The final destination can change based on device type, location, time, or whether security tools are detected.
- The chain ends at a fake login page, scam checkout, or a “download/update” prompt.
What traditional defenses miss
- Security tooling may inspect the first hop but not execute the full redirect chain like a real browser would.
- The final site can be personalized to avoid scanners (cloaking).
- Users see only the last page and often don’t realize they were redirected multiple times.
How isolation changes the game
- Isolation provides a safer default for ad-clicks and unknown redirectors by containing the entire chain away from the endpoint.
- Disposable sessions reduce persistent tracking and leftover state from redirect-heavy browsing.
- Policy can enforce stricter handling for known redirect patterns (shorteners, ad networks, free hosting).
Operational checklist
- Route ad-clicks and unknown redirectors into isolation by policy.
- Block downloads and browser notification prompts in isolated sessions unless explicitly allowed.
- Log and review redirect chains for high-risk events (credential prompts, download attempts).
- Use allowlists for critical vendor portals; discourage ad/search access for admin consoles.
- Pilot with marketing/sales teams who click lots of external links and tune friction carefully.
FAQs
Are redirects always bad?
No. Redirects are common on the web. The risk is when attackers use chains to hide a malicious final page or to evade scanning.
Why do attackers use redirect chains?
They can rotate destinations, personalize payloads, and make investigation harder by obscuring the true landing page.
How can IT detect malicious redirects?
Look for unusual hop counts, newly registered domains in chains, and redirects that lead to credential prompts or downloads.
Does isolation stop redirects?
It doesn’t stop the web from redirecting, but it contains the chain away from the endpoint and applies consistent policy controls.
References
- Google Safe Browsing — Google
- Cloudflare: Browser Isolation — Cloudflare