INTRODUCTION TO SUBDOMAIN TAKEOVERS
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
example.com
is the target and that the team running.
have a bug bounty programme. While enumerating all of the subdomains belonging to
example.com
— a process that we will explore later — a hacker stumbles across
subdomain.example.com
, 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
subdomain.example.com
, we discover the following 404 error page.
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
subdomain.example.com
— we have successfully claimed the subdomain. For demonstration purposes, the index page now displays a picture of a frog.
