Introduction
If you have never performed a subdomain takeover before or would like a fresh introduction, I have devised an example scenario to help explain the basics. For this scenario, let us assume that
is the target and that the team running.
have a bug bounty programme. While enumerating all of the subdomains belonging to
— a process that we will explore later — a hacker stumbles across
, a subdomain pointing to GitHub pages. We can determine this by reviewing the subdomain’s DNS records; in this example;
$ host subdomain.example.com
subdomain.example.com has address 192.30.252.153
subdomain.example.com has address 192.30.252.154
$ whois 192.30.252.153 | grep "OrgName"
OrgName: GitHub, Inc.
When navigating to
, we discover the following 404 error page.
The Takeover
Most hackers’ senses start tingling at this point. This 404 page indicates that no content is being served under the top-level directory and that we should attempt to add this subdomain to our personal GitHub repository. Please note that this does not indicate that a takeover is possible on all applications. Some application types require you to check both HTTP and HTTPS responses for takeovers and others may not be vulnerable at all.
Once the custom subdomain has been added to our GitHub project, we can see that the contents of the repository are served on
— we have successfully claimed the subdomain. For demonstration purposes, the index page now displays a picture of a frog.
