When doing subdomain enumeration, you are likely to encounter a domain that is a wildcard. Such domains respond to DNS queries with a record/records, which are not explicitly defined in the DNS zone. In other words, if the DNS zone does not hold a record for a particular subdomain, a fallback is made to its wildcard entry.
In the example above, the admin.0xpatrik.com and sub.0xpatrik.com respond with 1.2.3.4 and 4.3.2.1 respectively, while any other subdomain would respond with 1.1.1.1, not NXDOMAIN! This is a valid, yet obscure behavior of DNS servers.
Such a function can cause a lot of trouble because you will start enumerating targets, that doesn't even exist.
This post presents techniques to detect and filter the wildcard domains during subdomain enumeration.
Detection
One of the simplest indicators of the wildcard domain is a large number of its valid subdomains. The simplest way to confirm this case is by running a DNS query on subdomains that you are certain that does not exist as such:
As you can see, this query resulted in valid results! This is the first hint that you are probably dealing with the wildcard domain. To verify that this is indeed a wildcard domain, you can run one more test to confirm it:
Schema starting with a * (*.example.com) is used to denote wildcard entry. As you can see this resulted in another valid record set in the ANSWER section.
Perfect, you are now able to recognize wildcard domains. The real world is, however, a little more difficult than that. There is no rule, that the wildcard domain needs to be under the root domain. Take for example *.amazonaws.com and *.s3.amazonaws.com. As you will see after running the queries for these domains, only the latter responds with a valid record. Therefore, you need to recognize to which root or subdomain is a wildcard domain applied.
Filtration
We should be able to correctly filter out the non-existing domains from the existing ones. With that in our hands, we can continue with the recon and enumeration as there is no wildcard domain in the first place. However, this can't be done in all cases:
- Some configurations allow wildcard entries but do not respond to
*.example.comquery. - Some configurations allow all subdomains to resolve to one domain and different content is served based on
HostHTTP header (like*.herokuapp.com).
With this in mind, we can create a heuristic for filtering the non-existing subdomains under the root that allow wildcard entries like so:
- Given the domain (
something.sub.example.com), obtain its records (like 1.1.1.1) - Replace the highest subdomain level with
*and try to resolve it (*.sub.example.com) - If you get no results, continue until you reach the root domain (
*.example.com) - If you end up with no results, there is no wildcard domain and the given domain in step one is likely valid.
- If you get any response from wildcard queries, compare it to the results you got from 1. If these results equal, the domain is likely not valid.
- If these do not equal, the domain is likely valid.
It is important to compare the results with the wildcard results in higher domains. For instance, if both *.sub.example.com and *.example.com respond with valid results, you compare the results for *.sub.example.com.
I deliberately say records, because there are instances when wildcard queries respond with multiple records (e.g. *.herokuapp.com). When implementing automated filtering, you should compare sets instead of lists while many of the records can be unordered.
The last issue I want to talk about is anycast DNS. I have seen cases where the wildcard domain responds with multiple values, however, these are presented one at the time. In this case, automating the filtering is really tough as you need to enumerate all the possible values you would then compare against the potential subdomains.
Until next time!
