vulnerable to Subdomain Takeover

What would you say if one day you are visiting and you’d see this in your fancy web browser:
What are those fishes doing on the official USA Government Website?

Well, via a responsible disclosure, we proactively performed a Subdomain Takeover on a vulnerable subdomain of (see the proof).

A subdomain takeover is considered a high severity threat and boils down to the registration of a domain by somebody else (with bad intentions) in order to gain control over one or more (sub)domains. - Sweepatic Blog

Through our reconnaissance platform, we are able to create visibility in large dynamic digital footprints around the world and hunt for all kind of threats including active subdomain takeovers. When monitoring the domain we discovered a significant security gap which enabled us to take over their subdomain. Of course, we proactively secured it against threat actors and, through coordination by the National CSIRT in the US, we helped to make aware of this vulnerability.

In this blog post, we explain what exactly happened and how you can protect your organization from those very Subdomain Takeovers.

The discovery

So what happened to In June 2017, our reconnaissance platform alerted us on a suspicious subdomain

After an inspection by one of our Sweepatic hunters, we found that the HTTP request to resulted in HTTP code 404 (Not Found) on GitHub Pages.

GitHub Pages is a free web-hosting service provided by GitHub. Anyone can set up static websites using git repositories. On top of that you can customize the domain name of your GitHub Pages site.

As shown on the screenshot below, the points to CNAME record which in turn has A records pointing to AWS servers. The idea was probably to redirect the traffic for over AWS servers to one of GitHub Pages' websites.


Unfortunately, the subdomain was not registered in the GitHub Pages anymore. It is a pretty unusual setup because it is possible to use CNAME records directly in order to achieve the same behaviour. Therefore, the domain could have been registered by any attacker who in return would have full control over one of the subdomains.

What are the dangers?

A vulnerable subdomain like this presents many options to an attacker. It is perfect to setup an infrastructure to fuel several attacks e.g.

  • Phishing / Spear phishing
  • Malware distribution
  • Cross-site scripting (XSS)
  • “Man-in-the-browser” attacks
  • Brand / reputational damage

This makes it clear: an active, hostile subdomain takeover represents and is considered a high risk.

How to repair the domain?

In order to mitigate a subdomain takeover, you first need to create the visibility over all your DNS records and hunt for dangling CNAME records. This can be tedious hence you need to rely on automation. Once discovered, the remediation of the subdomain is simple, either you remove the subdomain from your DNS records or you point the subdomain elsewhere.

If you're passionately curious, our blog post on the principles of a Subdomain Takeover will explain the topic in more detail.

Responsible disclosure

After we discovered (and proactively remediated) the security issue in the digital footprint of one of the US-based government organizations, we submitted a responsible disclosure through the Incident Reporting System support system of the National CSIRT in the US at the end of June 2017. After followup with our contactperson, they then coordinated the responsible disclosure to, who secured their subdomain at the end of August 2017.

We believe this to be a prime example of the collaboration between the private and public sector in reporting security issues, denying opportunities for bad actors. Through several responsible disclosures, we were able to communicate and coordinate similar security issues to closure before any harm was done.

We hope this responsible disclosure is perceived as a positive message and an example on our ongoing research and collaboration in making organizations around the world more safe.