DNS Hijacking: Click, Clack, CNAME Jacked

1. What is DNS Hijacking?

DNS subdomain takeover remains one of the most overlooked and underestimated risks in modern digital infrastructure.

It occurs when a subdomain is configured to point to an external service that is no longer active but is still addressable via DNS.

In our experience, this usually happens when an organisation migrates from one domain to another — for example, from professionalcompanylimited.com to pcl.com, or examplecompany.co.nz to examplecompany.com.

In these situations, organisations often leave old infrastructure running or redirecting to allow their older client base to remain unaffected by the change.

As time goes on, these old domains and associated infrastructure are forgotten and slowly fall out of maintenance.

This leads to situations where DNS records that previously pointed to third-party applications (think ZenDesk, GitHub Pages) still point there, but the resource on the third-party service has expired and is free to claim again.

This can allow an attacker to claim the external resource (such as an abandoned cloud app or hosting environment) and gain control over traffic intended for the organisation’s domain — leading to risks ranging from phishing and brand impersonation to, in some cases, direct network compromise.

2. Technical Overview of Subdomain Takeover

A subdomain takeover occurs when a DNS entry (typically a CNAME or A record) points to an external service that has been decommissioned, deleted, or has expired, but the DNS record remains active.

If the corresponding resource is unclaimed, and an attacker can register the resource being pointed to, they can assume control over the traffic intended for the subdomain.

Commonly vulnerable services include:

• Cloud platforms (e.g., AWS S3, Azure Blob Storage, Google Cloud Storage)

• PaaS providers (e.g., Heroku, GitHub Pages, Netlify, Shopify)

• SaaS integrations (e.g., Zendesk, Bitbucket)

  
  

For a more comprehensive (but not exhaustive) list, we recommend taking a look at https://github.com/EdOverflow/can-i-take-over-xyz.

Typical attack path:

1. Discover active DNS records pointing to external services.

2. Identify records referencing unclaimed or deleted resources.

3. Register or claim the resource.

4. Control the subdomain and associated traffic.

3. Practical Discovery: Minimal Tools Required

Subdomain takeover can often be performed without any specialised penetration testing tools, typically only requiring a simple browser.

Examples of free and public resources:

• crt.sh — Certificate Transparency logs (to discover subdomains)

• SecurityTrails — DNS history and subdomain enumeration

• DNSDumpster — DNS reconnaissance

• Direct DNS querying via browser-based tools or CLI utilities ( dig, host)

  
  

Example: Subdomain Enumeration via Certificate Transparency

Utilising browser applications such as crt.sh current and historical DNS records can be identified which are related to TLS certificates. Resulting in subdomains such as:

• staging.example.com

• dev-portal.example.com

• oldapp.example.com

  
  

Verifying DNS Records

From the command-line simple tools such as dig or nslookup can be used to quickly identify whether these subdomains point to external services. For example:

dig staging.example.com # for Unix based systems
nslookup staging.example.com # for Windows based systems

Alternatively, tools such as Mxtoolbox's CNAME Look Up can be used to do this directly in the browser.

If a subdomain points to an external service (via a CNAME) like: staging.example.com. 300 IN CNAME staging-app.herokuapp.com.  and the Heroku app staging-app is unclaimed, takeover is possible.

4. Real-World Example

To demonstrate how accessible this attack is, we reproduced this vulnerability using our own DNS records and a GitHub Pages site.

Step One: Subdomain Discovery via Certificate Transparency

Using free tools like crt.sh, we identify subdomains based on their TLS/SSL certificates.

As we can see, blacklight.security has two subdomains, although typically the www subdomain is not very interesting.

Originally the example.blacklight.security domain pointed to a GitHub Pages site, which looked like this:

However, this page was just used for some viability testing during the organisation's inception, has long since been forgotten, and is no longer maintained. It won't look like this at present (but we can imagine that we pulled the above screenshot from archive.org or a similar service).

Step Two: External Service Analysis

Given the list of subdomains we obtained from step one, the goal now is to find out what exactly, at present, these webpages are hosting.

Visiting example.blacklight.security we are now presented with this page:

Uh oh — looks like one of the interns deleted the old GitHub Pages repository

Passage of time and changing of internal organisation infrastructure has obviously led to the deletion of the repository which this subdomain originally hosted. So now what?

Well, as the attacker, we identify where example.blacklight.security points.

We can use the dig command in the terminal:

Or this can be done using the browser, utilising tools such as mxtoolbox's CNAME Look Up function:

Now we can clearly see that the DNS entry for example.blacklight.security is a CNAME entry pointing to blacklight-security.github.io. We can also confirm this by navigating to blacklight-security.github.io and confirming that it displays the same page and sets the URL to example.blacklight.security.

Step Three: Hijacking the Domain

Anybody can create a GitHub Pages site, all that is required is a free account with GitHub. For example we could create a new account on GitHub, create a new repository, add a simple index.html file, and publish it to the world-wide-web.

Let's try that, we'll create a new GitHub account and a new repository with the name blacklight-security.github.io. We will also include the following index.html file:

<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Subdomain Hijacked</title>
    <style>
        body {
            margin: 0;
            padding: 0;
            height: 100vh;
            background: linear-gradient(135deg, #2c3e50, #3498db);
            display: flex;
            justify-content: center;
            align-items: center;
            color: white;
            font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
            font-size: 3em;
            text-align: center;
        }
    </style>
</head>
<body>
    This subdomain has been hijacked
</body>
</html>

The HTML file above is nothing special, its just a simple page with a gradient background and some text in the centre.

Then we can configure the repository as a GitHub Pages site under Settings → Pages.

Now we can input a custom domain in this handy little box:

Once a domain is entered, GitHub will first check to ensure that there is a valid and corresponding DNS entry that points to a GitHub Pages site. Well funnily enough, we know that there is a DNS entry which points to GitHub pages already; example.blacklight.security.

Let's try putting that in there:

Oh wow, it looks like our site is live at example.blacklight.security.

Lets take a look:

So we have successfully hijacked the subdomain example.blacklight.security  without having any access to the organisations DNS or NS servers, and without using any specialised tools except a web browser.

Notes

It is worth noting that in this example we have used a CNAME record and GitHub Pages as the target, this technique is also valid for A records and for any number of SaaS services. Consider taking a look at Can I Take Over ZYX? to get a glance at what services you are using which could be turned against you in the future.

5. Attack Impact and Risk Profile

Successful DNS subdomain takeovers may allow attackers to:

• Host malicious content under a legitimate domain (e.g., phishing portals).

• Deliver malware or command-and-control beacons.

• Hijack authentication flows (e.g., capturing OAuth redirect URLs).

• Leak sensitive session data via misconfigured cross-domain policies.

• Damage brand reputation by associating malicious activities with the corporate domain.

• Gain internal network access via hijacking firewall allow-listed domains.

  
  

The impact of a successful domain hijacking will typically be dependent on the third-party service that the subdomain points to. GitHub Pages is usually on the lower end of the impact severity spectrum, services such as Digital Ocean, or API SaaS services would rate higher.

Importantly, SSL/TLS certificates (via Let's Encrypt and others) can often be issued automatically for the compromised subdomain, allowing full HTTPS service under the organisation's brand.

6. Defensive Strategies

Importantly, there are a number of mitigations to help organisations protect themselves against attacks like these.

1. Comprehensive Asset Inventory

• Maintain an up-to-date record (asset inventory) of all subdomains, DNS records, and external services in use.

2. DNS Record Hygiene

• Immediately delete or update DNS records upon decommissioning services.

• Verify DNS configurations during cloud migrations and project shutdowns.

3. Regular Monitoring

• Continuously monitor Certificate Transparency logs ( crt.sh, Google CT API).

• Set up alerting for unexpected SSL certificates issued for your domain.

4. Subdomain Takeover Scanning

• Conduct regular scans against internal and public DNS records.

• Validate third-party services' subdomain ownership policies.

5. Provider-Specific Hardening

• Use wildcard catch-all records ( *) cautiously to avoid unintended delegations.

• Monitor services listed in Can I Take Over XYZ for known takeover risks.

6. Security Awareness

• Train development and operations teams to recognise and report obsolete DNS configurations.

7. Conclusion

Subdomain takeover is a technical threat with broad operational implications — ranging from customer trust erosion to regulatory liability.

It is fundamentally an asset management problem exacerbated by the widespread adoption of cloud services and rapid digital expansion.

Organisations that practice disciplined DNS management, monitor their external attack surface continuously, and conduct regular offensive security assessments will be better positioned to prevent these high-risk, low-effort attacks.