Organizations spend millions on security solutions and hire great talent for their security team – but sometimes a simple misconfiguration can leave an organization vulnerable to some serious subdomain hijacking. As more cloud services become available, the chances of such misconfiguration will continue to rise.

Someone can take over your subdomains easily and effortlessly. It is a lazy hacker’s dream come true. In this article we will learn what a subdomain takeover consists of, and how to use the Dome9 Compliance Engine to detect this vulnerability and fix the misconfiguration.

What is Subdomain Takeover?

Many websites use subdomains for different resources. If the website uses www.domain.com for the website, the subdomains can be mapped to other resources, for example: blog.domain.com points to the wordpress portal, docs.domain.com points to the hosted documentation solution, and so on. The subdomain can be mapped to 3rd party solutions or internal services.

Resource mapping is very easy in the cloud. In AWS it is common practice to point Route53 DNS to the CloudFront that serves as the CDN. CloudFront can be mapped to serve content from an ELB for dynamic content, or S3 for static content.

Subdomain takeover can happen when resources are decoupled, many times because the mapped object is removed. For example, an S3 bucket that was mapped to CloudFront was removed, but the record in CloudFront remains untouched. A client that tries to access CloudFront and ask for a resource that is mapped to the S3 bucket would see an error message like this one:

The 404 message is very revealing. It surrenders the exact issue: bucket does not exist. At this point, the attacker can start the takeover: go to AWS and create an S3 bucket with the name of the missing bucket. As bucket names are unique in S3, the missing bucket name is available. Once the new bucket is created, CloudFront will point to the new bucket, and the attacker can start serving malicious content to innocent clients.

A similar scenario can happen with many other services. This can happen very easily to a developer that is not aware of the ramifications of resource deletion. The worst part: this vulnerability is hidden. The security team may not even see it coming.

Detecting Subdomain Takeover using Scripts

Detecting configuration issues that may lead to subdomain takeover can be done using scripts. A lot of code writing is required. Here is an example of the steps (at a very high level) needed to detect wrong mapping between Route53 and CloudFront:

– Iterate over all Route53 hosted zones.

– For each hosted zone fetch the resource record set.

– Iterate over all the records that point to CloudFront distribution.

– For each CloudFront distribution try to resolve the CloudFront distribution.

– If the distribution does not exist – subdomain takeover vulnerability is found.

This example covers only the detection of decoupled Route53 and CloudFront. Similar scripts need to be written for other resources as well. The scripts need to run regularly, the service running it needs to be deployed, maintained and monitored. And of course, the scripts need to be applied across all the cloud accounts.

Surely there’s a better way…

Detecting Subdomain Takeover using the Dome9 Compliance Engine

The Dome9 Compliance Engine provides an easy way to detect subdomain takeover. The Compliance Engine uses an innovative language called the Dome9 Governance Specification Language (GSL) to build rules . GSL is human readable, and easy to write and maintain. Here is a similar example for wrong mapping detection between Route53 and CloudFront written in GSL:


Route53RecordSetGroup where recordSets contain-any [ type='CNAME' and records contain-any [ assetMetadata.type='CloudFront' ] ] should not have recordSets contain-any [ records contain-any [ assetMetadata.exists=false] ]


Detecting decoupled Route53 and load balancers can be done just as easy:


Route53RecordSetGroup where recordSets contain-any [ type='CNAME' and records contain-any [ assetMetadata.type='LoadBalancer' ] ] should not have recordSets contain-any [ records contain-any [ assetMetadata.exists=false] ]


How to repair the domain?

After detecting the dangling CNAME records it is time for remediation. The remediation of the subdomain is simple, either you remove the subdomain from your DNS records, or you point it to another subdomain.

Don’t let it happen to you!

It’s very easy to exploit a domain when misconfigured. Subdomain takeover is not a theoretical vulnerability – it has happened many times before. It happened to the US government. It happened to Donald Trump. However, subdomain takeover is easy to detect using the Dome9 Compliance Engine – give it a try with a free trial and test your domain today.