ZeroTrace OSINT
Redirect Analyzer
Every hop in a redirect chain — status, location, timing, cookies, final-URL TLS, cross-origin and protocol-downgrade flags.
The redirect analyzer follows an HTTP redirect chain hop by hop and reports what happens at every step. It is the right tool for tracing tracking links, phishing chains, and cloaked URLs.
What you get
For each hop in the chain:
| Field | What it tells you |
|---|---|
| Status code | 301, 302, 303, 307, 308, or a non-redirect terminal status |
| Location header | Where the hop sends the client next |
| Method | Which HTTP method was used for the next hop |
| Time | Round-trip time for this hop |
| Set-Cookie summary | Cookies set during the hop (count + names) |
| Cross-origin flag | Whether the hop crossed origins |
| Protocol downgrade flag | Whether the hop went from HTTPS to HTTP |
| Final-hop TLS info | TLS version, cipher, certificate subject for the terminal HTTPS URL |
| Final-hop title + Server | Page title and Server header at the terminal URL |
Why hop-by-hop matters
A modern redirect chain often has six to ten hops:
- The user clicks a link in an email.
- The link is a tracking-pixel host that records the click.
- Then a CDN-edge that performs geographic routing.
- Then the marketing platform that records attribution.
- Then the campaign-management host.
- Then the destination's own short-link domain.
- Then the destination's own canonical URL.
Inspecting the final URL alone misses all of this. The hop-by-hop view tells you exactly which hosts handled the request and what data they had access to.
Cross-origin and protocol-downgrade flags
| Flag | What it means |
|---|---|
| Cross-origin | The hop sends the client to a different origin (different host, port, or protocol). Common in marketing chains, suspicious in security contexts. |
| Protocol downgrade | The hop redirects from https:// to http://. Almost always a mistake or an attack. |
Both flags surface as warning chips on the hop row.
Final-hop TLS info
For the terminal URL, the tool runs a quick TLS check (a lite version of TLS inspector) and surfaces:
- Negotiated TLS version and cipher.
- Certificate subject (the leaf cert's CN / SAN).
- Validity dates.
If the final URL is HTTP, the TLS section is replaced with a "no TLS — HTTP destination" warning.
Final-hop title and Server
A GET against the final URL captures:
- The page title.
- The Server response header.
For phishing analysis, a destination titled "Sign in - Microsoft" with a Server header revealing it is actually Apache/2.4 (Ubuntu) is a classic mismatch worth flagging.
"Open final URL safely"
The result includes a one-click "copy as defanged URL" affordance. Copies the final URL with [.] substitutions so you can share it in a report or chat without anyone accidentally clicking it.
Always defang URLs before sharing them in chat platforms, email, or reports. A surprising number of "I just wanted to share the URL for context" messages get auto-rendered into clickable hyperlinks by chat clients. Defanging breaks that.
Cookies set per hop
Each hop's Set-Cookie headers are summarised: the count of cookies set and their names. Useful for spotting tracking-cookie cascades — modern marketing chains commonly set ten to twenty cookies across the redirect.
Pivots
| Click on... | Pivot to |
|---|---|
| Hop hostname | DNS, WHOIS, certificate transparency, IP geolocation (after resolution) |
| Final URL | Site analysis, Wayback, URL parser, robots/sitemap |
| Cookie domain | DNS lookup |
| Final-hop TLS subject | TLS inspector |
Bulk redirects
Bulk paste accepts many URLs and runs each through the redirect chain. Aggregate table shows initial URL, hop count, final URL, final status, cross-origin / downgrade flags — fast triage of a list of suspicious URLs.
Sources
- Direct HTTP requests to each hop (rate-limited per host).
- TLS handshake against the final URL.
The tool follows redirects up to a sensible cap (typically 20 hops) to avoid getting stuck in cycles.