Back to Basics: DNS Enumeration

For aspiring penetration testers who have not had much experience outside of labs such as Hack the Box or penetration testing courses, chances are that not a lot of emphasis was placed on DNS enumeration. Generally, courses cover this topic since it is important, but the lab environments that come along with the course typically do not heavily incorporate DNS enumeration as part of the intended attack path of a vulnerable machine.

Why should I care about DNS as a penetration tester?

There are a few reasons why DNS enumeration is important.

1. It can reveal the size of the enterprise of the target organization which can translate to the potential size of the attack surface. Enumerating the number of domains and sub-domains can reveal how large or small the organization may be. If one was conduct DNS enumeration of a Fortune 500 company, the result would be completely different than if one was to conduct the same enumeration for a start-up.
2. Virtual Routing may be enabled. Virtual Routing allows a web server to serve different resources depending on the domain name. Generally, the first thing we do is attempt to navigate to a web page using the IP address of the host (e.g. http://10.10.10.112) to see what the host serves us. Let’s say that the domain name “idontexist.htb” resolves to that IP address. Some would expect that http://idontexist.htb would serve the same page as it served by requesting http://10.10.10.112. If virtual routing is enabled, this is not always the case. In fact, if virtual routing is enabled, depending on how it’s configured, http://idontexist.htb may serve a completely different page than if you were to request http://10.10.10.112.

Please note that the reasons I listed above are not all-inclusive. I’ve listed a few to provide a case for why it’s important to thoroughly enumerate DNS like any other service. Now that we’ve got that out of the way, let’s break it down!

Identifying DNS Server

I will explain this in two different scenarios.

Scenario 1: You are attacking an enterprise environment

Within an enterprise environment, you’ll typically have dedicated servers that provide DNS service. Given this scenario, the easiest way to identify hosts provide DNS service is to search for port 53 across the subnet(s) within scope. A Nmap command similar to something below should suffice:

nmap -sC -sV -p53 192.168.x.0/24

Of course, replace the IP range appropriately. The host that has port 53 open will probably be the DNS server. Take note of this host.

Scenario 2: You are attacking a single machine

In this scenario, you’ll conduct your regular Nmap scan. If you find port 53 open, then chances are that the box also has DNS services running. If this is the case, take note of that.

Enumerate DNS Server

We will be using a retired Hack the Box machine called Cronos to explore DNS enumeration. First thing I will do is start a port scan.

We notice that port 53 is open so DNS service is likely running on this box.

First thing I am going to do is begin using a tool called nslookup to see if I can gather any information through reverse DNS.

Luckily, this query produced a sub-domain, ns1.cronos.htb, that appears to be the nameserver. We will confirm whether or not this is a nameserver by looking for record types later on. Based on this information we also have the domain name, cronos.htb.

Next, we are going to dig deeper. We’re going to conduct a zone transfer using a tool called dig. What I am going to do is use the domain name, cronos.htb as the parameter instead of the suspected nameserver. So the full command looks something like this:

dig axfr cronos.htb @10.10.10.13

We’ve passed the domain name and the IP address of the host with DNS service running pre-pended with the “@” symbol.

Based on this output, we can confirm that zone transfer revealed additional sub-domains. So far we have the following domain names available:

1. cronos.htb
2. admin.cronos.htb
3. ns1.cronos.htb
4. www.cronos.htb

We also know that ns1.cronos.htb is the nameserver based on the “NS” record type indicated in the output. So what do we do with this information?

Modifying the hosts file

There are two files on your Kali machine that you need to be concerned with. The first file is the /etc/hosts file, which looks something like this by default:

Within this file, you can map domain names and sub-domains to IP addresses. This file instructs your system to resolve to a specific IP address given the respective domain or sub-domain. Before we begin modifying this file, let’s do a quick test.

We know that a web server is running on this host, so let’s navigate to http://10.10.10.13.

What we get is a default Apache2 page. Now since we enumerated cronos.htb, let’s navigate to that in our web browser.

My browser can’t seem to find that resource. Now let’s add some entries into our /etc/hosts file. We are going to add a line that maps each of the domain names we enumerated. We can do this all in one line by separating each domain name with a space.

Now that we’ve done that, my machine should know to resolve cronos.htb to 10.10.10.13. Let’s try navigating to cronos.htb in the browser again after the hosts file modification.

Notice that we get a response from the server and that the page is different than when we navigated to http://10.10.10.13. The reason why we get different resources, even though we are resolving to the same IP address, is due to virtual routing. When the web server sees the IP address, it serves the default Apache2. When the web server sees a domain name being requested, it serves a completely different page.

We should be able to navigate to each of the enumerated sub-domains now as well.

Modifying the resolv.conf file

Before we go through this, let’s comment out the entry we made to our hosts file for the time being.

The resolve.conf file, also located in the /etc directory, is a file that tells your machine which DNS server to use to resolve domain names. By default, your file should look something like this:

Before we add any entries, in a new browser (to prevent cached content from populating), navigate to cronos.htb. We shouldn’t get a connection since our machine does not know how to resolve that domain name.

Now, let’s specify the nameserver as the 10.10.10.13. This should work because we know that DNS service is running on the host and we enumerated that the host has a nameserver, ns1.cronos.htb.

I placed this entry above the default nameserver because I want my machine to use the one on the target host first, and then if that fails, use the default nameserver. Let’s save this file and navigate to cronos.htb again.

Again, we see that modifying the resolv.conf file worked as well.

Last Thoughts…

Without DNS enumeration, there may be information that you are missing out on. In this example, we modified both hosts and resolv.conf files to get our machines to resolve domain names specific to the target host. Depending on the machine you are attacking, one method may work while the other does not, so it is imperative to test the machine. Please note that if you opt to use the hosts file instead of the resolv.conf file, each domain and sub-domain must be explicitly defined in the file for your machine to resolve the domain names.