Have you ever created an Azure web application, created a DNS record from your domain, and then deleted the web app without deleting the DNS record? Then you have just created a major security risk! I came across a fantastic article the other day on the Azure Security Docs page and figured I would capture it for you here.

What is a subdomain takeover?

The Microsoft article states that subdomain takeovers are a common, high-severity threat for organizations that regularly create, and delete many resources.

The takeover occurs when a user has a DNS record that points to a deleted Aure resource. These DNS records are called “dangling DNS” entries. CNAME records are the most vulnerable to this threat. A malicious actors can takeover the deleted name and redirect traffic intended for an organization’s domain to a site performing malicious activity.

Risks of subdomain takeover

Microsoft states the following about the risks:

When a DNS record points to a resource that isn’t available, the record itself should have been removed from your DNS zone. If it hasn’t been deleted, it’s a “dangling DNS” record and creates the possibility for subdomain takeover.

Dangling DNS entries make it possible for threat actors to take control of the associated DNS name to host a malicious website or service. Malicious pages and services on an organization’s subdomain might result in:

• Loss of control over the content of the subdomain – Negative press about your organization’s inability to secure its content, as well as the brand damage and loss of trust.
• Cookie harvesting from unsuspecting visitors – It’s common for web apps to expose session cookies to subdomains (*.contoso.com), consequently any subdomain can access them. Threat actors can use subdomain takeover to build an authentic looking page, trick unsuspecting users to visit it, and harvest their cookies (even secure cookies). A common misconception is that using SSL certificates protects your site, and your users’ cookies, from a takeover. However, a threat actor can use the hijacked subdomain to apply for and receive a valid SSL certificate. Valid SSL certificates grant them access to secure cookies and can further increase the perceived legitimacy of the malicious site.
• Phishing campaigns – Authentic-looking subdomains might be used in phishing campaigns. This is true for malicious sites and for MX records that would allow the threat actor to receive emails addressed to a legitimate subdomain of a known-safe brand.
• Further risks – Malicious sites might be used to escalate into other classic attacks such as XSS, CSRF, CORS bypass, and more.

Find the dangling domains in your subscriptions/tenant

To help customers with these types of issues, Microsoft has built some tools to help customer manage their DNS entries. There is a Powershell Cmdlet that is available for download here.

This tool is to be used by Azure customers to list all domain chains that have a CNAME associated with an existing Azure resource that was created on their subscriptions or tenants. Alternatively, for customers like Contoso, who have the CNAMES in the other DNS services pointing to Azure resources, the customer can provide the CNAMEs in an input file to the tool. You can use this tool by executing this as a PowerShell script.

1. Get all CNAMES (Option of querying all CNAMES for current tenant that you have acccess to, or take as input in a file)
2. Filter to those CNAME that have canonical name ending with well-known resource URLs: azurefd.net, blob.core.windows.net, azureedge.net etc.
3. For each CNAME in the above, check if a resource exists for this tenant that has the FQDN that matches with the canonical name in the CNAME.
4. For the CNAME records that do not have corresponding matching resource in the tenant, put it into a list of dangling sub-domains, while the CNAME records that do have corresponding matching resource in tenant goes into a separate list.
5. Make the complete list available to the customer in a tabulated and csv list that can be imported into Excel.

Here are the high-level steps typically used to run the tool:

To Gather all of that information use these steps:

1. Query all subscriptions for your user account or tenant. Use Get-AzureRmSubscription
2. For each subscription get all resource groups. Use Get-AzResourceGroup
3. For each Resource Group get all Zones. Use Get-AzDnsZone
4. For each DNS Zone, Get all record sets of type CNAME. Use Get-AzDnsrecordSet
5. Filter CNAMEs for the canonical name having ending part of URL as in table below.

Running the ‘Get-DanglingDnsRecords’ cmdlet

The cmdlet to find these entries is named: Get-DanglingDnsRecords. To use this tool you will need the following access:

• Azure subscription with read access to Azure resource graph
• Permission to download and install the AZ PowerShell Libraries. If you are new to working with Powershell on Azure check out this article Azure PowerShell Cmdlet Naming Convention And Discoverability | Build5Nines. This can also be performed from the Azure CloudShell.

To install the cmdlet use the following steps:

Run the following command in Cloud Shell

Install-Module -Name AzDanglingDomain Import-Module -Name AzDanglingDomain

To run the cmdlet using a If using a custom zone upload your zone records using the upload button:

Get-DanglingDnsRecords -InputFileDnsRecords .\zone.csv

Input Parameters

-InputFileDNSRecords 

Input Csv/Json filename with (CName, FQDN mapping), default None

-FetchDnsRecordsFromAzureSubscription

Switch to express the intent to query azure subscriptions, default off.

-FileAndAzureSubscription 

Switch to express the intent to fetch DNS records from both input file and from Azure DNS records, default off.

-InputSubscriptionIdRegexFilter 

Filter to run the query against matching subscription Ids, default match all.

-InputDnsZoneNameRegexFilter 

Filter to run the query against matching DNS zone names, default match all.

-InputInterestedDnsZones 

Filter to match the target matching domain zone names, default match all.

-OutputFileLocation 

Location of the output files produced; default current directory.

Get help examples

To get more help with the cmdlet use these commands:

Get-Help Get-DanglingDnsRecords -Examples

Example Output:

ound 87 CName records missing Azure resources; saved the file as: .\AzureCNameMissingResources.csv Output files contain dangling DNS records that needs further investigation.

Fetched 1 Azure resources; Saved the file as: .\AzureResources.csv

Fetched 63 Azure CName records; Saved the file as: .\AzureDnsCNameRecordSets.csv

Processed 24 CName records from input file: .\CNameDNSMap.csv

NameOfProcessSection : Time in Milliseconds

InputFileProcessingTime : 24

AzureLibrariesLoadTime : 3

AzureResourcesFetchTime : 2548

AzureDnsRecordsFetchTime : 10250

InputDnsCNameListProcessingTime : 3

AzureCNameListProcessingTime : 10

SummarizeTime : 11

ScriptExectionTime : 19754

TypeOfRecords : Details

ProcessedType : Parallel

AzureSubscriptions : 1

AzureResources : 1

AzureDnsZones : 1

AzureDnsRecordSets : 88

InputDnsCNameList : 24

AzureDnsCNameRecordSets : 63

AzureCNameMatchingResources : 0

AzureCNameMissingResources : 87

Here are a few links to the articles I reviewed for this post:

Prevent subdomain takeovers with Azure DNS alias records and Azure App Service’s custom domain verification | Microsoft Docs

Azure-Network-Security/Cross Product/Find Dangling DNS Records at master · Azure/Azure-Network-Security (github.com)

Take care,

@deltadan

About the Author