How to handle Dangling DNS and Subdomain takeover in Azure ?

What is Dangling DNS and risk of “Subdomain takeover” ?

Subdomain takeovers are a common, high-severity threat for organizations that regularly create, and delete resources. Which is very much obvious considering our Non-Prod environments.

A subdomain takeover can occur when you have a DNS record that points to a deprovisioned/decommission/deleted Azure resource.

Such DNS records are also known as “dangling DNS” entries. CNAME records are especially vulnerable to this threat. Subdomain takeovers enable malicious actors to redirect traffic intended for an organization’s domain to a site performing malicious activity.

A common scenario for a subdomain takeover:

Creation:

• You provision an Azure resource (AppService -WebSite) with a fully qualified domain name (FQDN) of asp-mytest-dev.azurewebsites.net
• You assign a CNAME record in your DNS zone with the subdomain myapp.test.myorganization.com that routes traffic to your Azure resource endpoint which is asp-mytest-dev.azurewebsites.net.

Deletion:

After succesful testing you deleted the resource, you WebApp. Maybe because of your cost constraints and best utilization of IaC. You deleted when you are not using it.

At this point, the CNAME record myapp.myorganization.com should be removed from your DNS zone. If the CNAME record isn't removed, it's advertised as an active domain but doesn't route traffic to an active Azure resource (because it is deleted — asp-mytest-dev.azurewebsites.net). This is the definition of a "dangling" DNS record.

Also, assume that you have enabled Azure AD authentication using App Registration for the resource endpoint. And the callback URL is inactive DNS record.

Takeover of in-active record:

1. Using commonly available methods and tools, a threat actor discovers the dangling subdomain.
2. The threat actor provisions an Azure resource with the same FQDN of the resource you previously controlled. In this example, asp-mytest-dev.azurewebsites.net.
3. Traffic being sent to the subdomain myapp.myorganization.com is now routed to the malicious actor's resource where they control the content.

Reference Microsoft

Loss of control over the content of the subdomain

• Cookie harvesting from unsuspecting visitors
• Phishing campaigns
• Further risks — Malicious sites might be used to escalate into other classic attacks such as XSS, CSRF, CORS bypass, and more.

How to handle “Dangling DNS” ?
Identify dangling DNS entries. To identify DNS entries within your organization that might be dangling, use Microsoft’s GitHub-hosted PowerShell tools “Get-DanglingDnsRecords”

How to handle “Redirect URIs for dangling DNS within App registration ?

I have a module published that take cares of analyzing all the App registration (of course within scope of your credentials) for redirect URIs analysis.
It fetches details of all redirect URIs that are NO more active/reachable and vulnerable to identity spoofing and other threats.

Module Name:

Install-Module -Name SubdomainTakeover

How to use it ?

There are 2 modes of running the command-

1. Providing App registration object ID, dedicated for single App registration (will make it parameterized array soon in future)

Get-RedirectURIs -AppObjectID '<App Registartion Object ID>' -verbose

Output: If you have any vulnerable URL, it will be resulted in table format, as you can see in the below screen shot.

2. Running it for the whole tenant across all App registration (Recommended)

Get-RedirectURIs -verbose

Output: Array of all infected URLs that are in-active and can be vulnerable for subdomain takeover.

As you see below table was generated as the outcome of the command. It includes 3 columns.
SPN_Name, App, Owner