Using PD tools to find my first subdomain takeover

Since joining PD in December, I've been learning a lot about our community and what it takes to be a modern security engineer. One of the biggest lessons I think I've learned is:

Gone are the days when there were very separate teams—red and blue have even become “purple” in many organizations—doing security. And like the terminology or not, security continues to “shift left” and move into “DevSecOps.” While anyone trying to sell you something with the buzzwords might not know it, practitioners are seeing how the worlds continue to combine. In that world, it can be tough to understand how to scan for, communicate about, remediate, verify and prevent future instances of vulnerabilities. That entire cycle is one some organizations struggle to get right and efficient.

Attackers (and their nicer cousins, bug bounty hunters) on the other hand don't have the constraints of being a large bureaucratic organization. They can explore the attack service and poke for vulnerabilities in a way that assumes nothing about how things “should” be and only focuses on how they “are.”

Recon

To start figuring out how things really are, you have to do reconnaissance. While it's valuable to have an inventory of assets, subdomains, and other internet-facing properties – you shouldn't assume that represents the entire attack surface area for your organization. You want to look through public data about subdomains with a tool like subfinder and ensure that you know what is out there.

Once you have the list of possible targets, you want to know what's really going on with each. That's where tools like httpx, naabu, and other tools can be useful – figure out what the exposed surface area is for each of these assets.

And once you know the entire breath of the surface area, then you need to be scanning for not just things you think could be wrong, but also common and new attack vectors that may come up. What makes nuclei so powerful here is twofold:

1. First, the community of open source contributors who update the baseline templates constantly to reflect the current state of the threat environment.
2. And second, the ability for you and your team to write your own templates in YAML – and easily communicate about vulnerabilities as code.

Using the nuclei template as the main communication point allows even large enterprises where detection, remediation, and prevention of vulnerability exploits may span departments and geographies to communicate efficiently and effectively about what they need to look for.

The next hidden power of all these tools we mentioned is the ability to create a meaningful pipeline to do all of this in a repeatable, continuous way, like say:

subfinder -d boleary.dev | httpx | nuclei -tags mytemplates

Creating a pipeline like that and then using the tooling to communicate and check for remediation allows your team – big or small – to think like an attacker and prevent more bad actors from gaining a foothold in your infrastructure. And once I had that in place, I was able to identify a possible subdomain takeover target with nuclei:

Subdomain takeover overview

So, what is a “subdomain takeover attack” anyway? Why are they important?

A subdomain takeover attack is a security vulnerability that occurs when a subdomain (e.g., subdomain.example.com) is pointing to a service (such as GitHub Pages, Heroku, etc.) that has been discontinued or deleted by its owner. An attacker can then claim this subdomain and set up their own content, effectively hijacking it. This can allow the attacker to carry out phishing attacks, host malicious content, and steal sensitive information, among other things.

The attack is generally achieved by exploiting a misconfiguration in the DNS settings for the subdomain, where the DNS records for the subdomain still point to the discontinued service. The attacker then registers an account with the discontinued service using the same subdomain name, and the service will then treat this account as the new owner of the subdomain.

Building the Proof of Concept (POC)

To build a proof of concept (POC) of a subdomain takeover attack using AWS Elastic Beanstalk, I followed the general steps below. Depending on the service that the target is using (AWS Elastic Beanstalk, GitHub pages, Heroku, etc.) the specific steps will differ, but the general principles will remain the same.

1. Find a target subdomain that is using AWS Elastic Beanstalk and has been discontinued or deleted by its owner, as we discussed in the recon session
2. From that target subdomain, note where the CNAME point – if it is to a publicly accessible part of the AWS infrastructure, it will be something like foo.region.elasticbeanstalk.com
3. Register an AWS account or use an existing one
4. Verify that the subdomain is pointing to the AWS Elastic Beanstalk service and is available for you to use.
5. Create a new Elastic Beanstalk application in your AWS account and deploy a simple website or application. You can even just start with one of the sample applications.
6. Verify that your new website or application is accessible from the subdomain.

By successfully executing these steps, you would have successfully demonstrated a subdomain takeover attack using AWS Elastic Beanstalk. You can then report the finding to the organization through their responsible disclosure program.

Remediation

To protect against subdomain takeover attacks, companies should take the following steps when decommissioning applications:

1. Remove all DNS records for the subdomain.
2. Ensure that the subdomain is no longer pointing to any external services such as AWS Elastic Beanstalk, Heroku, or other Platforms as a Service.
3. Remove the account associated with the subdomain from any external services.
4. Monitor the subdomain for any unauthorized activity.

By following these steps, companies can reduce the risk of subdomain takeover attacks and protect their sensitive information and intellectual property. Additionally, they should regularly review their DNS records and decommissioned applications to ensure that they are not vulnerable to subdomain takeover attacks. This should include regular scanning not just of known assets, but built in tools to scan for unknown assets.

In an ideal world, the deployment of applications to your domain would be made secure through CI/CD and deployment systems. These systems should be designed to clean up after themselves when destroying an application. However, in reality, teams within large organizations often have different standards, making it crucial for blue, red, and purple teams to implement safeguards against subdomain takeover attacks. To mitigate the risk, regular scanning of the entire exposed infrastructure is a must.