Let’s look into the subdomain takeover vulnerability, what makes a web app vulnerable to it, and how to avoid this from happening.

The best way to understand Subdomain take over is to understand what is happening in the DNS layer, so let’s take a look at our example using the command dig.

Understanding output of dig

When we run dig CNAME domain we are generally asking, "Does this domain have a CNAME record?" CNAME Record is an alias record for another domain, useful when multiple names should refer to the same host or service. However, this sometimes can also make an application vulnerable if the CNAME is living outside your control.

Let’s take a closer look to understand why this domain is not vulnerable to domain takeover.

Digging for CNAME

dig CNAME myapp.api.acme.com

When we run `dig CNAME domain` we are generally asking, “Does this domain have a CNAME record?”
CNAME Record is an alias record for another domain, useful when multiple names should refer to the same host or service. However, this sometimes can also make an application vulnerable if the CNAME is living outside your control.

Let’s take a closer look to understand why this domain is not vulnerable to domain takeover.

[..redacted..]
;; QUERY: 1, ANSWER: 0
;; AUTHORITY SECTION:
acme.com. 60 IN SOA ns-cloud-b1.googledomains.com. cloud-dns-hostmaster.google.com.
[..redacted..]

From the output, we can see ANSWER: 0 , so there is not CNAME record. When we asked if the above domain had a valid CNAME record the answer was no. However, it does not mean it does not point anywhere, it only means it doesn’t use a CNAME record to do so.

There still could be a A, AAAA, ALIAS for the record, which is the case on our example.

The dig output shows

• There’s no CNAME record currently set for myapp.api.acme.com.
• The fact that there’s no CNAME tells you that the is not an alias for any other domain.
• The query falls back to the authoritative zone for acme.com, managed on Google Cloud DNS. So the subdomain myapp.api.acme.com doesn’t point anywhere — but it’s still defined in the DNS zone.

Why it’s not vulnerable to takeover?

• The domain does not have a CNAME record
• Also, if the CNAME record was created inside the SOA zone of the primary domain, under the owner’s control (instead of pointing to a third-party provider like Vercel, GitHub, Netlify, etc.), it is less likely to be vulnerable
• There’s no delegation to any external service.
• The record simply doesn’t exist, but the parent zone (acme.com) still owns it.
• Therefore, attackers cannot register or claim this subdomain anywhere, because it’s not pointing outside Acme’s controlled DNS zone.

How a Subdomain takeover happens?

Below is a diagam showing the normal state flow of an application that is vulnerable to subdomain take over that is working correctly, then when it goes into limbo state which is when the application is removed but the CNAME record still exist within the ACME DNS zone.

At last what happens when an attacker successfully takes over the subdomain.

What would make it vulnerable?

• if the external resource no longer exists
• An attacker can reclaim or recreate that resource (e.g., register the same GitHub repo name or S3 bucket).
• The traffic then would be re-directed to the attackers website

Example of a vulnerable configuration:

dig CNAME test2.cybersamurai.co.uk
[...redacted...]
;;QUERY: 1, ANSWER: 1
;; AUTHORITY SECTION:
test2.cybersamurai.co.uk. 300   IN      CNAME   v0.app.
[...redacted...]

• We can see by ANSER:1 , there is a CNAME record for the domain.

The CNAME for this record is been re-directed to v0.app which is a third-party making this domain vulnerable to subdomain takeover. If the app is deleted anyone could create a new App within v0.app with that same name and instantly serve content under test2.cybersamurai.co.uk

⚠️ What would make it vulnerable

myapp.api.acme.com would become vulnerable if Acme added a record like:

myapp.api.acme.com.  CNAME  stage-app.herokuapp.com.

In that case:

• The CNAME still exists.
• Heroku would return no such app.
• An attacker could register a Heroku app named stage-app and take control of the subdomain.

How a CNAME can protect (or not) a subdomain

• A CNAME itself doesn’t “protect” a domain — it depends on where it points and who controls the target.

However:

• If the CNAME points to a domain owned and controlled by Acme(e.g., another acme.com subdomain or a GCP-managed service), that’s safe — because no one else can claim that target.
• If the CNAME points to a third-party platform (e.g., GitHub Pages, AWS, Netlify), it becomes potentially vulnerable if that resource is later removed.

So the rule is:

Learning is practicing

The best way to learn is to write it, and if possible why not write your own program to help solidify your understanding of a subject, and this is what I did.

There are a few good tools already to check for Domain take over I am familiar with.

• subzy

subsy run --targets domains.txt --timeout 30

• subjack

subjack -w domains.txt --timeout 30 -t 100 -v

• nuclei

nuclei -tl | grep takeover

However, I find the best way to learn is to try writing something myself, so I can see the code in action. As well as an old friend told me, "That best way to learn is repetition repetition repetition"

New Tool Subtake

Here is a tool I created called subtake

Subtake is available on github and will perform the checks we have talked about on this article.

How it works

The main program is written in bash script build using dig and regex, simple yet powerful tools.

It will perform a lookup on the domain specified or file list provided, If the result from the dig CNAME domain is available, and there is a CNAME for the domain within our vulnerable list, and the IP does not exist, this will tag the domain as "Vulnerable". If the CNAME is within our vulnerable list and the IP exist the domain is tagged as "At Risk" if the CNAME does not exist or is not within our vulnerable list the domain is marked as "Safe" Any other results its marked as "Unknown".

If you enjoy the article or have any feedback on anything mentioned comment below.