How to create a subdomain enumeration toolkit
A domain name is an important part of the reconnaissance process during a security assessment or even for many bug bounty challenges. In this article, we’ll look at how a domain can be classified. Within this context, two scenarios of how to take advantage of domain misconfigurations will be analyzed. Finally, we’ll discuss building a subdomain enumeration.
A domain represents a label for IP addresses on the internet — a short link associated with an IP address. In detail, a domain can be analyzed based on two different perspectives: vertical domain correlation and horizontal domain correlation (shown in Figure 1).
- Vertical domain correlation: Vertical domain correlation is a process that reveals domains in the same domain base. This process is also known as subdomain enumeration.
- Horizontal domain correlation: Horizontal domain correlation is a process of finding other domain names, which have a different second-level domain name but are related to the same entity.
Figure 1: Examples of vertical and horizontal domain correlation.
Taking advantage of subdomain enumeration
Discovering subdomains can unveil potential weaknesses and vulnerabilities. For instance, one of the popular vulnerabilities within this context is domain takeover. By exploring this misconfiguration flaw, a malicious agent could claim a vulnerable subdomain. As a result, the criminal could launch social engineering campaigns against a target audience or even take advantage of legacy systems that are still communicating with those domains to obtain sensitive data, e.g., session cookies.
Imagine that the subdomain “xxx.infosecinstitute.com” was pointing to a specific IP address, e.g., a shared host, and is related to an old service from the company. Meanwhile, you have access to the shared hosting service and have the possibility to upload content to the vhost folder of “xxx.infosecinstitute.com”. Here, you can take advantage of human failure: the DNS entry was not removed and decommissioned correctly.
In this scenario, the subdomain “site.infosecinstitute.com” is redirecting to a CNAME entry denominated: “website.pt”. Imagine that this domain is free and can be acquired — you could purchase it and set up a malicious page under that domain. From this point on, you could use a legitimate subdomain and disseminate malicious campaigns impersonating the entity behind the domain.
There are many possible scenarios that we could describe here, nonetheless, the goal of this article is to provide a simple way to create a subdomain toolkit to help security professionals find misconfigurations/vulnerabilities of this nature.
Creating a subdomain toolkit
This task can be accomplished using tools available on GitHub, namely Sublist3r, Amass, MassDNS and SubOver. Figure 2 presents a proposed workflow for creating a simple toolkit for domain enumeration using these tools.
Figure 2: Subdomain enumeration and monitorization workflow.
In detail, creating a subdomain toolkit can be divided into two phases: a) Domain enumeration module and b) Monitorization module.
Domain enumeration module
During this phase, several tools to create the maximum number of subdomains for a specific domain can be used. For instance, the target domains could be loaded from an input file as well. Those domains are passed onto a cluster where tools such as Sublist3r and Amass execute the domain enumeration process that uses online reconnaissance tools, common dictionaries, and brute-force attempts with permutations. The file outputs for each tool are generated and additional actions are required: deleting the subdomain repetitions and ensuring that the data is normalized.
As a next step, the usage of a DNS resolver such as MassDNS can retrieve a more detailed analysis of the new subdomain candidate. After that, the results are stored in a database that can be continuously updated by other modules or tools.
The collected data must be monitored both in an offensive and defensive perspective. After obtaining a normalized database with valid subdomains for a large group of target domains, the data can be used by security professionals or bug bounty players during their tasks. Through this module, the subdomains are used to find misconfigurations on DNS entries, such as CNAME and MX.
Scenario 2, described above, is a perfect example of this situation. Since performing a manual analysis is time-consuming, there are tools like SubOver that can be used to automate this process (Figure 3).
Figure 3: SubOver proof-of-work.
From this point on, other modules could be developed and added to this toolkit to fulfill the user’s needs. A module to detect domain expiration, to validate the use of HTTPs protocol by default and so on, could be other possible candidate modules to take in account after populating the database.
How to mitigate subdomain takeover
The rule of thumb is monitoring. Monitoring every domain can be carried out in order to prevent potential scenarios of this nature. Looking for dangling CNAME entries on DNS is a simple rule to prevent and alert for potential problems.
For example, in the Microsoft world, a subdomain takeover can occur when you have a DNS record that points to a deprovisioned Azure resource (Figure 4).
Figure 4: Subdomain takeover example diagram (Microsoft).
According to Microsoft: “when a DNS record points to a resource that isn’t available, the record itself should have been removed from your DNS zone. If it hasn’t been deleted, it’s a dangling DNS record and creates the possibility for subdomain takeover”.
Loss of control over the content of the subdomain, cookie harvesting from unsuspecting visitors and phishing campaigns are some examples of how this kind of vulnerability could be abused by malicious agents.
From this article, we noticed that a domain is a very common thing when thinking on the Internet. Weaknesses related to the domain’s configurations are a big challenge to manage and crooks can take advantage of this real problem.
As observed, wrong management and monitorization of domains can be an entry point that crooks could exploit to perform nefarious scenarios such as social engineering schemas, collecting sensitive information of legacy systems and more. Another possible scenario discussed during this article is the domain takeover vulnerability, where crooks could claim a subdomain.
The take-home message here is domain monitoring. This should be seen as a crucial piece of work to prevent these kinds of scenarios and closing the door to potential security problems.