During attack surface scanning, we often start by enumerating the target's domains and subdomains. Subdomains provide a lot of intelligence as they can link unrelated hosts, such as cloud instances, to the target or its subordinates.
Enumerating subdomains is not an easy task. We cannot simply ask the authoritative DNS server to give us all the records (technically it is possible using AXFR transfer, but it is not typically allowed by default). Therefore, we need to develop techniques to obtain the subdomains using various methods, such as:
As we know, not all valid subdomains can be found using these techniques. Some subdomains might no longer be valid, which is preferable because we can filter them out using active DNS resolution. The more problematic issue arises with subdomains that do exist but are not returned from our enumeration process.
The problem is that some subdomains might be "silent" – they don't have any TLS certificates issued, their webpages are not indexed by search engines, and no passive DNS monitor has detected them yet. The only popular technique that we haven't mentioned above is DNS (subdomain) brute forcing.
DNS brute forcing is a time and network-intensive process. Firstly, a list of possible subdomains is generated, typically using a list of the most popular subdomain names. Then, a DNS resolver is used to find the valid candidates from this list. For small DNS zones, the likelihood of finding a valid domain is relatively low. Why is that?
DNS naming schemas are unique
There is no standard for naming DNS resources. Variations can occur due to the native language of the company, specific keywords used by the company (such as product names), or simple changes (like using "-" instead of "."). For instance:
You see, pkjapp and indiadatacenter are not words that would be included in any brute forcing list.
To take the best aspects of DNS brute forcing and optimize it to be more efficient and targeted, we have created dnsgen. It is an open-source tool that, based on provided valid subdomains, generates a list of possible subdomains that might exist. Then, a simple DNS resolution reveals the valid subdomains from the list. Not only is dnsgen faster than generic DNS brute forcing tools, but it also creates a tailored list of possible subdomains for each target.
(For demo purposes, let's say that wordlist contains just one word: stage)
foo.example.com -> stage.foo.example.com, foo.stage.example.com
foo.bar.example.com -> 1.foo.bar.example.com, foo.1.bar.example.com, 01.foo.bar.example.com, ...
foo01.example.com -> foo02.example.com, foo03.example.com, ...
WORD and WORD-. foo.example.com -> stagefoo.example.com, stage-foo.example.com
WORD and WORD-. foo.example.com -> foostage.example.com, foo-stage.example.com
stage.foo.example.com -> otherword.foo.example.com, anotherword.foo.example.com, ...
- is used for a split on some subdomain level. For instance mapp1-current.datastream.example.com has mapp1, current, datastream words. To prevent the overflow, user-defined word length is used for word extraction. The default value is set to 6. This means that only words strictly longer than 5 characters are included (from the previous example, mapp1 does not satisfy this condition).
The screenshot below shows dnsgen output from single domain. Please note, that the list of domain does not mean that the domain is valid. It simply shows the possibility of the domain existence.
To verify the existence of particular subdomain, you have to run the list through DNS resolver. Refer to GitHub project's page to learn more about installation and usage.
dnsgen has gained popularity in the cybersecurity community and is now widely used for attack surface mapping. Kali Linux has even added dnsgen to its list of official tools.