The Problem with Static Blocklists Malicious ads on Google Ads rarely land directly on a known bad domain. Instead, they route through a chain of redirects that rotates domains faster than blocklists can update. When attackers register a fresh domain, let it sit for a few hours, and then point users to it via a series of 302 redirects, even legitimate ad platforms can abuse this technique. Static blocklists fail because they only check the final destination. An attacker can create a new domain, run it briefly, and move on before your list refreshes. By the time the entry is added, the domain has already been used enough times to appear benign. This creates a persistent blind spot that security tools miss. What You Will Learn How to trace a multi-hop redirect chain and record timing per hop Why hop count and timing variance are stronger signals than domain reputation alone A practical Python analyzer that scores chains dynamically Common failure modes and how to mitigate them How to extend the tool with configurable policies and whitelists The Redirect Pattern The typical malicious chain starts with a seemingly legitimate Google Ad click. The user lands on a domain that returns a 302 redirect to a CDN edge server. That CDN then serves a landing page that evaluates browser features, clears cookies, and finally delivers the exploit or payload. Each hop strips referrer headers and resets User-Agent expectations, making it hard for traditional filters to recognize the pattern. The most telling indicator is not the domain itself but the pattern of the chain: Number of hops – longer chains are harder to predict and easier to automate Timing between hops – attackers may insert deliberate delays to evade time-based scanners Header manipulation – repeated removal of referrer information and rotation of User-Agent strings By focusing on these behavioral signals, we can catch novel domains without ever knowing their names in advance. Build the Analyzer This script follows a redirect chain, records timing and headers at each hop, and scores the result. It uses HEAD requests to avoid downloading payloads, keeping bandwidth low and preventing accidental execution. import requests import time from typing import List, Dict def analyze_redirect_chain(url: str, max_hops: int = 10) -> List[Dict]: """Follow a redirect chain and collect metadata for each hop.""" session = requests.Session() hops = [] current = url for _ in range(max_hops): start = time.monotonic() # HEAD prevents downloading the body, saving bandwidth and avoiding execution resp = session.head(current, allow_redirects=True, timeout=15) elapsed = time.monotonic() - start hops.append({ "url": current, "status": resp.status_code, "location": resp.headers.get("location"), "elapsed_ms": round(elapsed * 1000, 1), "referrer_policy": resp.headers.get("referrer-policy"), "headers": dict(resp.headers), }) # Only continue if we got a redirect response if resp.status_code not in (301, 302, 303, 307, 308): break current = resp.headers["location"] return hops The function captures the status code, next location, elapsed time, and the referrer policy at each step. This data feeds into a scoring system that weighs hop count, delay patterns, and header anomalies. Configuration Options You can tune the analyzer with a small YAML configuration file. Below is an example showing how to adjust the maximum hop limit, enable a whitelist of known advertising domains, and set custom thresholds for scoring. analyzer: max_hops: 12 whitelist_domains: - google.com - doubleclick.net - adsense.net score_threshold: 0.75 ignore_known_platforms: - google.com - facebook.com - amazon.com With this setup, the tool respects a predefined list of legitimate ad platforms while still catching novel domains that attempt to mimic them. Why Static Lists Fail A static blocklist checks the final domain against a known-bad set. Attackers easily bypass this by creating a fresh domain, running it for a few hours, and then pointing users to it via a multi-hop chain. By the time your list is updated, the domain has already been used enough times to appear normal. Approach Evasion Resistance Maintenance Cost False Positive Risk Static blocklist Low Low Low Redirect-chain fingerprinting Medium-High Medium Medium Behavioral analysis at endpoint High High Low Fingerprinting the chain structure—counting hops, measuring timing variance, and tracking header stripping—catches novel domains without requiring prior knowledge of their names. This makes the defense adaptive rather than reactive. Failure Modes to Watch Legitimate marketing funnels also use multi-hop redirects. A score based solely on hop count will flag real campaigns. Adding a whitelist of known ad-platform domains reduces noise while maintaining sensitivity. CDN churn: attackers leverage Cloudflare or Fastly URLs that are also used by legitimate sites. Pairing chain fingerprinting with TLS certificate analysis helps distinguish legitimate CDN endpoints from adversarial ones. HEAD request rejection: some servers return 405 for HEAD requests. Falling back to a GET with a Range: bytes=0-1 header avoids downloading the body and prevents accidental execution. Rate limiting and throttling: aggressive scraping of redirect chains can trigger server-side protections, causing the analyzer to miss legitimate traffic. Implementing exponential backoff and respecting Retry-After headers mitigates this risk. Encrypted or obfuscated paths: attackers may use encoded URLs or unusual path structures. Including a heuristic layer that flags anomalous path lengths or unexpected query parameters adds another safety net. Key Takeaways Malicious Google Ads evade static blocklists through multi-hop redirect chains, not through a single suspicious domain. Timing and header behavior per hop are stronger signals than domain reputation alone. A redirect-chain analyzer like the one above provides a dynamic fingerprint you can update without waiting for blocklist vendors. Always pair automated detection with a human review step; false positives in ad-blocking can break legitimate business workflows. Extending the tool with configurable whitelists and scoring thresholds makes it adaptable to different environments and threat models. Source How I advertise malicious software on Google Ads — I added a defensive detection script, a comparison table of mitigation approaches, and documented the failure modes that the original post did not address. Support this work These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming. USDT, USDC or USDD · TRC-20 (Tron) TFTNsfyomKrnUutRjBTGVULp19ByW29KbY