Hijacking 8000+ CloudFront Domains

Over the past few weeks, we have been exploring some new OSINT data sources and techniques. During the course of this, we realized we had an easy way to identify an enormous number of domains that were vulnerable to takeover attacks. Let me explain…

Subdomain Hijacking Impact

Before we get into the technical details of this attack, I wanted to highlight the impact of a hijacked subdomain.

  • An attacker can host whatever content they want on a hijacked subdomain, so they could abuse the reputation of the domain to deliver malware or host a command and control channel.
  • Many websites scope session cookies to the parent domain, so a hijacked subdomain can be used to completely take over an authenticated user's session in this scenario.
  • While subdomains vulnerable to hijacks usually don't have content on them, there are often many old links still pointing to these domains. An attacker can leverage this traffic for click fraud or browser based cryptocurrency mining.

CloudFront Domain Hijacking Background

There has been plenty written about CloudFront and how it has potential for domain hijacks so we won’t go into a deep explanation. What follows is enough of an overview to follow the rest of the blog. If you are interested in more details, here’s a good walk through of hijacking a single domain: https://blog.zsec.uk/subdomainhijack/.

CloudFront is a content delivery network (CDN), which is generally used to cache content in various places around the world to improve load times, reduce back end server load, etc. Anyone can sign up for an AWS account and create a CloudFront “distribution” which is what Amazon calls the configuration defining where traffic goes and how it is cached. A distribution gets a cloudfront.net subdomain when it is created and any traffic to this domain will receive a response (could be cached, or not) from the origin server specified in the distribution.

You can also assign custom domain names to a distribution. To do so, you have to set a CNAME record for the domain that points to a subdomain of cloudfront.net, and also add the domain to the distribution. Now when someone browses to this domain, it resolves to regional CloudFront edge servers, and then Amazon sends traffic to the distribution that has the domain attached. If you are using Amazon’s Route 53 DNS service, you don’t need the CNAME, you can just point the domain to CloudFront.


If a domain is pointed to CloudFront but not associated with a distribution, then it is vulnerable to being hijacked. An attacker can simply add the domain to their own distribution, at which point Amazon will route traffic to whatever origin the attacker specified.

Amazon prevents domains from being associated with multiple distributions, so while a domain is associated, it is safe.

Searching & Hijacking

The target of our search is domains that point to CloudFront but are not associated with a distribution. There are two ways that a domain could be pointing to CloudFront.

  1. It could have a CNAME to [something].cloudfront.net
  2. It could resolve to a CloudFront edge server IP address (direct A records usually mean a domain is using Amazon’s own DNS)

Our data source for this search was Rapid7 Project Sonar’s forward DNS scan. We used the A response dataset which contains the A responses for all forward DNS names known by Project Sonar (some 1.5 billion lines). This includes CNAME responses.

First, we extracted all the domains that had CNAME records pointing to CloudFront. Then we searched for all the domains that resolved to IPs in the CloudFront edge server ranges. (Shout-out to the awesome grepcidr tool!)

We scanned all of these identified domains, looking for the error page that displays on unassociated domains. As far as we can tell, unassociated domains will always display this error, but not all domains with this error are unassociated.


Having narrowed down the list of domains to potentially vulnerable ones, the only way to know for sure was to attempt to associate the domains with CloudFront distributions. We wrote a Boto script to do this, since there were far too many domains to deal with by hand.

At this point, we had tested all known (by Project Sonar) domain names that either have a CNAME to CloudFront or resolve to it directly, and hijacked the vulnerable ones. 


You may have already seen where we missed more… There can be multiple CNAMEs in a row before a domain finally resolves to an IP. Here’s what I mean:


So we took the list of domains we identified as pointing to CloudFront, and looked for all of the domains that had CNAMEs pointing to those.

It’s worth noting that there are a handful of middle-man CDN or DNS services that account for some of these domains “in the middle”. For example, specs.firstdata.com is a real website hosted on CloudFront, but it first points to specs.firstdata.com.fastestpath.net which points to d37ko4b2tw5vil.cloudfront.net. While specs.firstdata.com is properly associated with a distribution, specs.firstdata.com.fastestpath.net was not. (Since fastestpath.net doesn’t host any content, this isn’t a particularly impactful subdomain to hijack, but good to be aware of nonetheless.) CloudFront routes traffic based on a request's Host header, so it won't see these middle domains.


Here's what that looks like in dig:


More often however, chained CNAMEs are just being used to redirect other domains to an organization's main website. If all of these other domains are not added to a distribution, then they become vulnerable. For example, www.example-corp.com might have a CNAME to www.example.com which then points to CloudFront. But if www.example-corp.com wasn't added in CloudFront, it can be hijacked.

Damage Report

We had hijacked a bit more than 8000 domains after all of this. There was A LOT of traffic hitting these. This suggests that many of these domains were still referenced on production websites that get lots of users. While we just hosted an explanation page at the root of these domains, an attacker could have served malicious content to every request. (Think lots and lots of crypto miners…)


We ultimately transferred these domains to Amazon where they assigned them to their own distribution with an explanation page.

Just to give you a sense of the scope, here are some of the domains we hijacked subdomains of:

  • adobe.com
  • mozilla.org
  • msn.com
  • wsj.com
  • mlb.com, nhl.com
  • 33 .gov, 5 .gov.au, 1 .gov.uk, and 1 .gov.tw subdomains
  • 20 .edu subdomains
  • And a lot of other domains you'd recognize


While we prevented 8000 domains from being abused, there are constantly more that become misconfigured. Amazon has a warning message that will sometimes show up when you remove a domain name from a distribution (I first saw it about a month ago, but it has never shown up consistently). This warns users that if a CNAME record is left but a domain isn't in a distribution, then it is vulnerable.


Organizations can protect themselves by monitoring their DNS records carefully to avoid orphaned CNAMEs. That is a lot easier said than done for most large companies however. MindPoint Group just released a tool, cloudfrunt, designed to identify misconfigured domains that's worth checking out. Amazon recommends never deleting CloudFront distributions, just disabling them. This would prevent CNAMES from ever being disassociated.

On Amazon’s side, it would be nice to see a verification step to prove you actually control domain names that you are adding to a distribution. Even just forcing CNAMEs to match distribution names would solve the problem. That isn’t the kind of rule you can just turn on overnight however, so don’t hold your breath.


There’s not a technical vulnerability here, we are just making use of misconfigurations and design decisions. Despite this, hijacking subdomains can still have real implications; attackers can steal the full session/cookie data from cookies scoped to the parent domain, host malware, or generally cause some damage to a brand.

Hopefully the recent research on subdomain takeovers brings attention to this topic and helps organizations better protect their resources.