Tracker Cloaking & Multi-Stage Redirect Chains: How Phishing Evades Security Scanners

Modern phishing infrastructure doesn't serve a malicious page to every visitor. It can't afford to — doing so would get the domain blocklisted within hours. Instead, threat actors deploy cloaking engines that inspect each incoming request and serve completely different content depending on who is asking. Security scanners see a clean webpage. Real human victims see a credential harvesting portal. This technical architecture is why a URL can pass every automated safety check and still be actively malicious.

1. What is Tracker Cloaking?

Cloaking is a server-side decision: before returning any content, the server inspects the HTTP request attributes and routes each visitor to a different response. The same URL serves two completely different experiences depending on the fingerprint of the incoming connection.

In legitimate marketing contexts, cloaking was historically used for SEO manipulation — serving content-rich pages to Googlebot while showing different content to human visitors. Google explicitly prohibits this. In the phishing context, cloaking serves the opposite purpose: showing clean content to crawlers and malicious content to people.

The cloaking decision tree typically evaluates, in order:

• Client IP Address and ASN: Known security vendor IP ranges (VirusTotal, Palo Alto Networks threat intelligence, Microsoft Azure, Googlebot) are routed to benign destinations — often google.com or wikipedia.org. The attacker maintains a list of "safe to redirect away" IP blocks that covers most automated scanners.
• User-Agent String: Requests carrying headless browser signatures (Puppeteer, Selenium, PhantomJS) or non-mobile user agents are identified as automated analysis. Some cloaking engines also blocklist user agents belonging to known sandbox environments.
• HTTP Referer Header: Requests reaching the cloaking server without a Referer matching the expected campaign delivery platform are treated as direct access — which automated scanners typically produce.
• One-Time Token: The original phishing email contains a unique token in the URL. The cloaking server checks that this token exists and has not been consumed before. Automated scanners crawling the URL without the token (because they extracted the base URL from link scanning, not from the email itself) receive a 404 or redirect to a benign page.
• Time-to-Click: Email security sandboxes detonate links within milliseconds of message delivery. Human victims click hours or days later. Cloaking engines can be configured to reject clicks faster than a defined threshold (e.g., <1 second from email timestamp) as sandbox detonation attempts.

2. Anatomy of a Real Redirect Chain

A documented phishing redirect chain from a 2024 Microsoft 365 credential harvesting campaign:

[Step 1: Link in Phishing Email]
https://t.campaign-track.net/r/a7f2b9c1?token=9A8F7B6C

    │  HTTP 302 — Marketing tracker with unique victim token
    ▼
[Step 2: Cloaking Gatekeeper]
https://gate.verify-cdn-auth.com/check?ref=t.campaign-track.net&tok=9A8F7B6C

    │  Server inspects IP, User-Agent, token validity, and time-to-click
    ├── If: known scanner IP / headless UA / missing token
    │       → HTTP 200: serves google.com redirect page (appears clean)
    │
    └── If: real victim fingerprint + valid token
            → HTTP 307 Temporary Redirect
                ▼
[Step 3: AiTM Reverse Proxy]
https://login.microsoft-account-security.org/common/oauth2/v2.0/authorize?...

    │  Proxies the real Microsoft login page while capturing session tokens
    ▼
[Step 4: Victim enters credentials + MFA]
    │  Attacker's proxy intercepts both the password and the session cookie
    ▼
[Step 5: Victim redirected to legitimate Microsoft page]
    — Victim believes login succeeded normally —
    — Attacker now has a valid authenticated session cookie —

This chain demonstrates why checking only the first URL in an email is insufficient — the final malicious destination may be four hops removed, and intermediate steps appear clean to automated analysis.

3. Redirect Types and Their Detection Complexity

4. The Adversary-in-the-Middle (AiTM) Proxy — How Sessions Are Stolen Despite MFA

The most sophisticated end-stage in phishing redirect chains is the AiTM reverse proxy. Rather than hosting a static clone of a login page, the attacker runs a real-time proxy that:

1. Receives the victim's browser request
2. Forwards it to the legitimate target (e.g., login.microsoftonline.com)
3. Returns the real login page, proxied through the attacker's server
4. When the victim enters credentials, the proxy intercepts them before forwarding to Microsoft
5. When Microsoft responds with a session token (post-MFA), the proxy intercepts that too
6. The victim sees a successful login — the attacker now holds a valid authenticated session cookie

The reason MFA does not protect against AiTM: TOTP codes, SMS codes, and push notifications all verify that the user is who they claim to be, but they do not verify that the server they're authenticating against is who it claims to be. Only hardware-bound authentication (FIDO2 security keys, passkeys) binds the credential to the origin domain, making it physically impossible to use on a proxied domain — the credential simply fails to authenticate at the AiTM layer.

5. How to Detect Cloaked Redirect Chains

Detecting cloaked URLs is hard from a corporate desktop or scanner because the cloaking engine is specifically designed to defeat those environments. Effective analysis requires:

A. Vary the Request Fingerprint

A cloaking engine makes its decision based on IP, user-agent, and headers. To bypass it, the analysis must come from an IP address and user-agent that the cloaking engine classifies as a real human victim. Edge compute platforms (running on residential-adjacent IP ranges, not corporate datacenter IP blocks) are more likely to receive the malicious response than a scanner running from an AWS or Azure datacenter IP.

B. Follow the Full Chain Including JS Redirects

A redirect checker that only follows HTTP status codes (301/302/307) misses JavaScript-based redirects. Complete analysis requires executing the page in a headless browser, waiting for any setTimeout-based redirects to fire, and observing the final destination URL after the full JavaScript execution cycle completes.

C. Decode Encoded Parameters

Base64-encoded redirect parameters are common: ?url=aHR0cHM6Ly9ldmlsLmNvbQ==. A scanner that evaluates only the top-level domain of the URL misses the encoded downstream target entirely. The analysis must decode and recursively inspect all URL-encoded and Base64-encoded parameters.

D. Check for Token Requirements

If a URL contains a unique token parameter (e.g., ?t=9A8F7B6C), the cloaking engine may require that token to be present and valid before serving the malicious content. Scanners that analyze the base URL without the token see only the clean response. The token-bearing URL in the original email is the one that needs to be analyzed — not a stripped version.

6. Analyzing Redirect Chains with IncogSay

IncogSay's Redirect Chain Checker follows the complete HTTP redirect path including 301, 302, 307, and 308 redirects, decodes Base64-encoded URL parameters, shows every intermediate hop with its status code and timing, and reveals the final destination URL. For suspicious links where JavaScript execution is needed, the URL Scanner runs a full analysis including domain age, SSL validity, typosquatting detection, and entropy scoring on the final resolved destination.

Neither tool sends the URL to your browser or executes it on your device. Analysis runs at the Cloudflare edge network, and results are returned as a structured report — your machine never makes a connection to the suspicious domain.

If you receive a suspicious email with a link you need to investigate: copy the URL including any token parameters, paste it into the URL Scanner, and review the redirect chain and threat score before any member of your team clicks the original link.