Discover Dangling Domains that point to your cloud assets to prevent subdomain takeover

Dangling domains are DNS records that point to a domain or subdomain that no longer exists or is not configured properly. It occurs when a domain or subdomain has been deleted, but the DNS record that resolves the domain or subdomain still exists in the DNS server. A dangling domain can occur for several reasons, including if the owner of the domain or subdomain forgets to remove the DNS record, or if the service associated with the domain or subdomain is discontinued or moved to a different location. Dangling domains can become problematic as they can be exploited by attackers for malicious activities such as phishing attacks, spamming, and distributing malware. 
 
To fully understand how this security misconfiguration can result in a complete attack path, we first need to understand what DNS server and DNS records are and how they correlate. 
 
What is DNS? 
 
DNS stands for Domain Name System. It is a hierarchical decentralized naming system used to translate domain names into IP addresses, essentially acting as a phone book for the internet. For example, if we open our web browser and type “lightspintest.net”, a request is sent to the DNS server asking for the IP address behind “lightspintest.net”. The response to this request exists in a DNS resource record (RR) in the zone file of the DNS server which is responsible for the “lightspintest.net” domain. There are various types of DNS resource records where each contains different types of information, depending on its purpose. For example, an “A” record maps a domain name to an IPV4 address, while a “MX” record specifies the mail server responsible for accepting email messages for the domain. Another common type of DNS resource record is “CNAME” (canonical name), which acts as an alias and maps one domain name to another.  

Once a request is sent, a DNS query for the alias will resolve to the CNAME record value. The security issue of a dangling domain can happen in several types of DNS resource record types, but in this post, we will focus on “CNAME” records, pointing to unclaimed resources specifically in cloud services. 

Cloud Services and Dangling Domains 

Some cloud services allow users to create temporary subdomains to have a unique DNS name for their resources. These unique DNS names are generated by the cloud providers with a certain pattern and usually are non-changeable, but some services do allow to choose the name of the service and integrate it in the DNS name as long as the name chosen is unique globally across all cloud provider and contains only characters which are valid for DNS name. 
For example, let's say we want to create a website under “news.lightspintest.net”. To do so we need: 

For the purpose of the demonstration, we chose to register our domain in Amazon Route53 and host our website as a static website in Amazon S3 bucket. To be able to route the traffic successfully from “news.lightspintest.net” to the bucket we need to create an S3 bucket with the same exact name as the domain or subdomain, in this case the bucket name should also be named “news.lightspintest.net”. 

We enable the ’Static website hosting’ feature in the bucket and receive the following endpoint address:

After creating the bucket, the next step is to create the DNS resource record in Route53.  
We will be using the endpoint we were given above. The address is composed of the name of the bucket + one of S3 domains (there are several more domains S3 use) and this is the address we will use in our record:

As mentioned above, we use CNAME record since we want the subdomain to be used as an alias to the resource to which it routes the traffic. Now that we are done with the configuration, if we browse to ”news.lightspintest.net” we get:

So far so good, so where is the issue? 
 
Managing DNS records can be tiresome. Cloud administrators often create, change, update but mostly delete many cloud resources, some of which have records pointing to them. Once a resource with such configuration is deleted but the DNS record is kept, we get what is called a ‘dangling domain’; a domain that is not attached to any resource on the other side.  

Dangling domains can lead to subdomain takeover, an attack that occurs when attackers gain control over a subdomain caused by a dangling domain. Once taken over, attackers can exploit the misconfiguration by creating phishing websites used for credentials or cookie harvesting or for simply defacement purposes. 
 
We have decided to explore various cloud services across the major cloud providers to better define the potential services that can be involved in subdomain takeover. To do so, we first started by researching the already known services (such as AWS S3 and ElasticBeanstalk) and making sure that they still apply to this attack. We simulated multiple cases, with several domains and kept our notes on how each service acts depending on different configurations. We wanted to check which services are most common among our customers when it comes to routing their traffic. To do so we started by querying AWS Route53 , GCP Cloud DNS, Azure DNS and pulled all the data of the records that are from the type CNAME. For each record, we separated the prefix and suffix so that we will have a better look at the number of the services and their kind. Once we had our list, we started testing each service to check if we could perform a subdomain takeover. 

The table below shows the cloud services we explored and the domain suffixes they provided: 

The Process: 

Before diving into the process, we want to take a step back and look at our setup. We used Route53 as our DNS server (like in the static website example from above) to test all the cases from the table. We created an instance of each service, took the endpoint address that was generated and created a DNS record for each service with a unique subdomain record name. After waiting a bit for the DNS server to propagate all the records, we started our simulations.  

In the example below, we created an application in ElasticBeanstalk. The URL that was generated by the service is lightspin-test1.us-east-1.elasticbeanstalk.com. An appropriate CNAME record was added to our DNS hosted zone as shown below: 

The record name elastic.lightspin.net is our subdomain that we assigned to the record value. This means that if we browse to elastic.lightspin.net the traffic will be redirected to our ElasticBeanstalk application. To better understand how this works we will look at the response to our request using dig command. The dig (domain information groper) command is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the queried name server. 

In the picture above, we can see that after querying our URL we are presented with two important outputs. The first is the status 'NOERROR'. This means that the server was able to successfully find the requested DNS record and return it in the response.  

The second output is in the answer section. We can see that the response for our URL is of a type CNAME and it points to lightspin-test1.us-east-1.elasticbeanstalk.com, the resource behind it.  
 
Now, if we go to elastic.lightspintest.net we get:

Great! The application is up and running. But what would happen if we decided to take the application down, delete the ElasticBeanstalk resource completely and not update the DNS CNAME record accordingly? In this case if we try to go to elastic.lightspintest.net we get the following error: 

It seems the website is no longer available. Let's see what the dig command returns: 

The response returns the status 'NXDOMAIN'. This indicates that the domain name does not exist in the DNS system and cannot be resolved to an IP address. If the domain name does not exist, it means that there is now a dangling DNS record, a record that is not attached to any cloud resource with a potential to be overtaken by attackers by simply registering the same resource with the same name (lightspin-test1) in their own account and thus routing the traffic to their malicious application.  

This is exactly what we did. We created another ElasticBeanstalk application in another demo account and registered it with the same name (lightspin-test1) and in the same region but with different content. 

Now, if we go back to elastic.lightspintest.net we are redirected to a different page, the “attackers” page:

ElasticBeanstalk is just one example of many other services. We created a simple html file with the caption “This site belongs to me now” and a picture of an attacker, but in the real world attacker put a great deal of effort to disguise themselves and their actions by creating websites that look like legit websites.  

Research Results: Cloud services which are potentially vulnerable to subdomain takeover 
 
While analyzing many services, we concluded that not all services behave the same way. For example, not all of them returned “NXDOMAIN” after deleting the service resource. We also found that there are two criteria that these “takeoverable” services share. 

For example, let's look at Azure Traffic Manager. When creating a new traffic manager profile we give the profile a name, for example demo-profile. This user provided profile name is used to compose the unique network identifier of the new traffic manager profile. The full domain network identifier will be demo-profile.trafficmanager.net. After the creation of the profile, the name does not change. That is opposed to several other services, such as Azure Front Door. In Azure Front Door, it is possible to name the endpoint in any name, but after clicking on the ‘create’ button, an additional random value is added to the final endpoint name. For example, if we name our endpoint fd-poc, the final name will be fd-poc-g2gvvvafdfrerh0cf.z01.azurefd.net. 

The table below summarizes the detected cloud services which can be “takeoverable”: 

Conclusion 

Undetected dangling domains are a real threat to any company. They can occur in any cloud provider. By taking control over the resource the traffic is routed to, attackers can perform malicious activities such as phishing attacks or distributing malware.  

In one of Lightspin’s recent version updates, we added a dangling domain analyzer to help our customers find all the resources that need to be remediated. This subdomain takeover analyzer is categorized as DNS Security and the risk is Dangling Domains Takeover. We have extended our detection for dangling domain to all three cloud provider’s DNS services (Route53 in AWS, Azure DNS in Azure, and Cloud DNS in GCP). 

For each one of the above managed DNS services, we analyze the records in all hosted zones and search for references to a non-existing asset. This type of misconfiguration is named “Dangling Domain” and it can cause a Subdomain Takeover.  

Check out our platform for more details on how to deep dive into this risk category.