Domain Name System (DNS) can provide valuable data during the reconnaissance phase. If you do not already understand DNS, you may want to take some time to get a good grasp of the service and how it works. At a very basic level, DNS is used to translate domain names into IP addresses. Luckily for us, there are many tools available that are excellent at extracting the data that we need from name servers. An example of the information you are able to gather includes:
|
Record |
Description |
|---|---|
|
CNAME |
Alias, used to tie many names to a single IP. An IP address can have multiple CNAME records associated with it. |
|
A |
Used to translate a domain or subdomain name to a 32-bit IP address. It can also store additional useful information. |
|
MX |
Ties a domain name to associated mail servers. |
There are other record types that can be collected from DNS tools as well; the records listed in the table are the most popular, and often the most useful.
nslookup is a DNS querying tool that can be used to resolve IP addresses from domain names or vice versa. This tool is used to query any given nameserver for specific records. Although nslookup is not the most powerful DNS tool in our testing toolkit, you can rely on the fact that it will be installed when you need it. It is cross-platform and will be found preinstalled on most operating systems.
Tip
During the following examples, we modified the command output to maximize the learning experience.
We intend to help you understand the format and the meaning of the output. In many cases, we substituted the original domain name(s) that was used with example.com/net/org and fictional IP addresses (usually non-routable IPs). Do not expect to replicate the output directly; instead focus on the concepts described, and then practice these steps on domains and servers that you have proper permission to perform testing on.
To perform a quick lookup for the IP address of the example.com domain name, we enter the following into a Kali terminal session:
# nslookup example.com
You will be presented with output in the following format:
Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: example.com Address: 127.1.72.107
The server at 8.8.8.8 is a public DNS server made available by Google™. The #53 UDP is the port being used when making the request. The preceding example output indicates that example.com resolves to 127.1.72.107.
Results can be validated using alternative DNS nameservers. In the following example we change the DNS nameserver to 156.154.70.22, which is the IP address of a name server offered by Comodo Secure DNS® to provide secure browsing to the public. It is beneficial to have a listing of several publicly available DNS servers when performing your testing. These can be used as a sanity check of sorts when dealing with a compromised DNS server. We also query for nameservers associated with example.com:
root@kali:~# nslookup >server Default server: 8.8.8.8 Address: 8.8.8.8#53 Default server: 8.8.4.4 Address: 8.8.4.4#53 >server 156.154.70.22 Default server: 156.154.70.22 Address: 156.154.70.22#53 > set type=ns >example.com Server: 156.154.70.22 Address: 156.154.70.22#53 Non-authoritative answer: example.com nameserver = ns51.example.com. example.com nameserver = ns52.example.com.
This example began by initializing nslookup and then proceeded to establish the variables from within the nslookups command console. We started by typing server, which displayed the current value of 8.8.8.8. After that, we determined that we wanted to use a different server; consequently we typed server 156.154.70.22 because we were specifically looking at example.com's nameservers. We defined the type to be ns (nameservers) by entering settype=ns.
Once the variables have been set, we can query countless domain names by typing the name, such as example.com, and pressing Enter.
Everything that we have done thus far can be simplified into a single command line:
root@kali:~# nslookup -type=ns example.com 156.154.70.22
We invoked nslookup, used an option of type=ns to pull the associated nameservers, provided the domain name that we want the information as example.com, and finally, we specified that we would like to use 156.154.70.22 as our resolving DNS nameserver. This will result in the following output:
Server: 156.154.70.22 Address: 156.154.70.22#53 Non-authoritative answer: example.com nameserver = ns51.example.com. example.com nameserver = ns52.example.com.
Any time that a command-line tool is executed, the output can be sent to a file for later review. This is especially important once you start to build your own scripts to automate your testing—for example, nslookup example.com > example-resolv.txt.
As previously stated, nslookup is an excellent choice given that it is generally preinstalled on all platforms. If you are using a pivot point, for instance, you can rest assured that this is one tool that you will have available by default. As nslookup can be executed from a single command-line prompt, you can easily create a script that automates the task of extracting information about many domains or hostnames, then have the output placed into a text file.
- In Kali, open a terminal session and type
nano AutoM8. Then press Enter. - In the nano editor, type the following code in which we initiate the bourne shell with
#!/bin/sh, parse each line item in theDomainNames.txtfile into theHOSTNAMEvariable, and then output the string "Getting name servers for"followed by the currentHOSTNAMEbeing parsed. We then use thenslookupcommand to perform the nameserver lookup using our specified public nameserver at8.8.8.8:#!/bin/sh for HOSTNAME in `cat DomainNames.txt` do echo "Getting name servers for [$HOSTNAME]" nslookup -type=ns $HOSTNAME 8.8.8.8 done
- Press Ctrl + O and then press Enter to confirm saving your data.
- Press Ctrl + X to exit back to the terminal screen.
- Type
nano DomainNames.txt. - In nano, enter the following:
example.com example.net example.org
- Press Ctrl + O followed by Ctrl + X to save the file.
- In the terminal, we will need to make the
AutoM8file executable by typing:# chmod +x AutoM8 - Now, run the
AutoM8script by typing:# ./AutoM8 - You should see output similar to the following format:
root@kali:~# ./AutoM8 "Getting name servers for [example.com]" Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: example.com nameserver = ns52.example.com. example.com nameserver = ns51.example.com. Authoritative answers can be found from: "Getting name servers for [example.net]" Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: example.net nameserver = ns51.example.com. example.net nameserver = ns52.example.com. Authoritative answers can be found from: "Getting name servers for [example.org]" Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: example.org nameserver = ns52.example.com. example.org nameserver = ns51.example.com.
- Now type:
# ./AutoM8>NameServerListing.txt # cat NameServerListing.txt
You have now created a simple script named AutoM8 that can be used to append the output into any file you like. We validated this using cat to look into the NameServerListing.txt file.
Ideally, you will be using tools that have an XML output available to you so that results can easily be imported into MagicTree or Dradis; however, when performing penetration testing on a daily basis, you will want to know how to create some basic tools for your own special needs. Shell scripting can be very powerful; Python, which is the tool of choice for many penetration testers, is even better.
If you take a look at the output of the various examples, you should note that you learned a great deal about our targets already. We know which nameservers are used, and we know that all three domains use the same nameservers. We also validated the domain names that we resolved to certain IP addresses. This is the type of data that will be very useful in later stages of your penetration test. Now, let's move on to some of the more powerful tools we have at our disposal.
Domain information groper (Dig) is a powerful alternative to nslookup. It has the capability to run command-line options; or a file can be piped into it directly when multiple lookups need to be performed. Dig will use the /etc/resolve.conf file to cycle through your nameservers unless a nameserver is specified. Dig has a very long list of options that can be used to gather exactly what you are looking for.
Tip
There is a website at http://www.digwebinterface.com/ that provides dig functionality to the public.
To initiate the basic command from Kali type dig example.com from the terminal command line. Here is an example of this command when run on our sample domain:
root@kali:~# dig example.com ; <<>>DiG9.9.5-9+deb8u2-Debian<<>>example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56376 ;; flags: qrrdra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 78294 IN A 10.1.1.1 ;; Query time: 32 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun *** * **:**:** **** ;; MSG SIZE rcvd: 45
This verbose output indicates the version of Dig, which global options were selected by default, whether there were any errors, and of course that the A record for example.com contains 10.1.1.1. You also learn that the currently used nameserver is at 8.8.8.8. In addition, we are provided with the time that the query was run, which can be very useful when piecing together data at a later date. DNS records can be changed, and having the date stamp from previous runs of Dig can be useful.
Let's dig a little deeper. We will pull all records for the example.com domain:
# dig +qr www.example.com any
This will pull all DNS records that are available for the example.com domain due to the any option, and the +qr switch will print the outgoing query. The result will include the header and footer data as seen previously, but will also list the following records:
;; QUESTION SECTION: ;www.example.com. IN ANY ;; ANSWER SECTION: example.com. 86400 IN NS ns1.example.com. example.com. 86400 IN MX 10 mx111.example.com. example.com. 86400 IN A 127.208.72.107 example.com. 86400 IN NS ns2.example.com. example.com. 86400 IN SOAns2.example.com.hostmaster.example.com. 2011020501 28800 7200 604800 86400 example.com. 86400 IN MX 10 mx99.example.com.
Zone transfers (AXFR) will allow you to pull an entire record set down from a nameserver at once. If successful, you will be provided with a listing of all information on the nameserver from one simple command. In secured environments, it is highly unlikely that zone transfers are enabled as they give an attacker a wealth of data with regard to hostnames and other information. We will now review the steps necessary to perform a zone transfer on the example.com domain. As with everything discussed within this book, you need to have the proper permission to perform this type of activity for your client:
- Open up a Kali terminal window.
- Type the following and press Enter:
# dig @ns1.example.com example.com axfr - Review the results:
; <<>>DiG9.9.5-9+deb8u2-Debian<<>> @ns1.example.comexample.comaxfr ; (1 server found) ;; global options: +cmd ; Transfer failed.
Our results indicate that the transfer has failed. In this case, the administrator of the nameserver has properly disabled the ability to perform zone transfers. Now, we will try another name server on the same domain and see if zone transfers are disabled on it as well.
- Type:
# dig @ns16.example.com example.com axfr - Review the results:
; <<>>DiG9.9.5-9+deb8u2-Debian<<>> @ns16.zoneedit.comexample.comaxfr ; (1 server found) ;; global options: +cmd example.com. 7200 IN SOAns16.zoneedit.com.soacontact.zoneedit.com. 2011409732 2400 360 1209600 300 example.com. 7200 IN NS ns14.zoneedit.com. example.com. 7200 IN NS ns16.zoneedit.com. mail.example.com. 300 IN MX 1 mail1.example.com. testmachine.example.com. 300 IN A 192.168.1.1 irc.example.com. 300 IN A 192.168.1.1 mail1.example.com. 300 IN A 192.168.1.1 note.example.com. 300 IN TXT "This is an example of a note" example.com. 7200 IN SOAns16.zoneedit.com.soacontact.zoneedit.com. 2011409732 2400 360 1209600 300 ;; Query time: 383 msec ;; SERVER: 69.64.68.41#53(69.64.68.41) ;; WHEN: Wed Oct 12 16:04:17 2011 ;;XFR size: 10 records (messages 10, bytes 579)
When reviewing the record pulled for example.com, we find several points of interest. It seems that example.com has several subdomains that are directed at the same IP address. If this site had not been set up strictly as an example, you would have real IP addresses to systems that could be enumerated. Also, there is a TXT record containing unnecessary information. In addition, it can be said that the naming convention is both inconsistent and informative.
If you want to learn more about zone transfers, take a look at https://digi.ninja/projects/zonetransferme.php. The owner of that website has done an excellent job of detailing how zone transfers work.
We have been discussing the basic usage of Dig. Now, we will touch upon a more advanced usage of this tool.
Dig is versatile and allows you to extract the data in many different output formats.
We can eliminate the command information section of the output by using +nocmd. It must precede the domain name in order to be effective.
+noall informs dig that we do not want the display flags as part of the command output.
The +answer can be toggled to display only the answer section.
root@kali:~# dig +nocmd +noall +answer example.com
This will result in the following output:
example.com. 44481 IN A 192.168.1.10
Any options discussed within this section can be used when shortening your output results. This makes it easy to use tools such as awk and grep to further manipulate your results.
This command will allow you to determine the version of bind the nameserver is running unless it has been specifically restricted or changed by the server administrator. Remember to substitute example.com with a nameserver that you have permission to use:
# dig +nocmd txt chaos VERSION.BIND @ns1.example.com +noall +answer
This will result in the following output:
VERSION.BIND. 0 CH TXT "8.4.X"
We determined that this particular name server is running BIND 8.4.X. This information can prove to be extremely valuable when enumerating vulnerabilities.
At times, it will be necessary to resolve IP addresses to domain names. There is no need to swap back to nslookup to perform this task as you can simply type:
# dig +nocmd +noall +answer -x 192.168.0.1
Your output would look something like this:
10.0.0.1.in-addr.arpa. 8433 IN PTR 43-10.any.example.org.
The previous command allowed us to determine the domain name associated with 192.168.0.1.
We can chain commands using dig. In the following example, we use our shortened output format to provide us with the A record of example.com and example.net and then request a reverse lookup on 192.0.43.10.
# dig +nocmd +noall +answer example.com example.net -x 192.168.1.10
The resulting output is as follows (the domain name has been replaced with example.org in this output):
example.com. 37183 IN A 192.168.1.10 example.net. 54372 IN A 192.168.10.11 10.0.0.1.in-addr.arpa. 6937 IN PTR 43-10.any.example.org.
If you would like to see the route that dig is taking to resolve your domain name, you can use the +trace option as follows:
# dig +trace example.com
Instead of having to write a script to a loop that evaluates a list of domain names in a file like we had to when using nslookup, dig can use the -f option. We can use the dig command format to perform these batch jobs.
- We will begin by creating a new
txtfile using the nano text editor included in Kali. Open up a terminal shell in Kali and typenano digginIt.txt. - In nano, type the following code. Note that each command needs to be on its own line to function properly:
+nocmd +noall +answer example.com +nocmd +noall +answer example.net +nocmd +noall +answer example.org ns
- Press Ctrl + O to write and save the file.
- Press Ctrl + X to return to the terminal.
- Invoke the
digcommand with the following command:# dig -f digginIt.txt - The results will be displayed on your screen:
example.com. 33996 IN A 192.168.1.10 example.net. 51185 IN A 192.168.1.10 example.org. 82826 IN NS a.example.net. example.org. 82826 IN NS b.example.net.
We have successfully created and executed a Dig batch job. This could be put to many uses including creating and checking against baselines, performing repetitive tasks from one penetration test to the next, or simply keeping track of the commands used to perform this portion of your reconnaissance. Store the text file used in the batch job so that you can at a later time validate the findings.
In a secured environment, DNS brute-forcing is likely to be your best bet in determining which hosts are used in a noncontiguous IP space. Kali contains several tools that address this need. We will be discussing fierce, created by RSnake, which is fast and efficient at DNS brute-forcing. It will begin with determining the IP address of the domain, looking up the associated nameservers, and then working its way through your dictionary word list. The tool supplies an example word list that can be used for testing, but you should replace or supplement it with dictionary words more specific to your needs as soon as possible.
In Kali, open up a terminal session and access fierce that contains a help section that can be accessed using:
# fierce -h
The most basic method of using fierce is to use:
# fierce -dns example.com
This will result in an output similar to the following:
DNS Servers for example.com: ns1.example.net ns2.example.net Trying zone transfer first... Testing ns1.example.net Request timed out or transfer not allowed. Testing ns2.example.net Request timed out or transfer not allowed. Unsuccessful in zone transfer (it was worth a shot) Okay, trying the good old fashioned way... brute force Checking for wildcard DNS... Nope. Good. Now performing 1895 test(s)...
This output indicates that the first step taken was to locate the nameservers for the example.com domain. The next step is to check the server to see if a zone transfer can be performed. As you learned previously, zone transfers will extract all known domain information from the server with one command. There will be no need to brute-force domain names if you can simply pull the entire record set at once.
Some domains include wildcard DNS records. This will cause any subdomain you use to be resolved regardless of whether it exists or not. In this case, there were no wildcard DNS entries found.
The number of tests that are run will be determined by how many words are in your supplied word list. As we did not specify which list to use in the preceding example, hosts.txt, which resides in the /usr/share/fierce directory on Kali, will be used by default.
Here, fierce is used against a domain that allows for zone transfers:
# fierce -dns example.com
In this case, the brute-forcing functionality of the tool is not necessary and thus not initialized. See the following results for details:
DNS Servers for example.com: ns14.zoneedit.com ns16.zoneedit.com Trying zone transfer first... Testing ns14.zoneedit.com Whoah, it worked - misconfigured DNS server found: example.com. 7200 IN SOAns16.zoneedit.com.soacontact.zoneedit.com. ( 2011413884 ; Serial 2400 ; Refresh 360 ; Retry 1209600 ; Expire 300 ) ; Minimum TTL example.com. 7200 IN NS ns14.zoneedit.com. example.com. 7200 IN NS ns16.zoneedit.com. example.com. 300 IN A 192.168.1.1 mail.example.com. 7800 IN MX 10 mail1.example.com. testmachine.example.com. 300 IN A 192.168.1.1 irc.example.com. 300 IN A 192.168.1.1 mail1.example.com. 300 IN A 192.168.1.1 note.example.com. 300 IN TXT "This is an example of a DNS text record." www.example.com. 300 IN A 192.168.1.1 There isn't much point continuing, you have everything. Have a nice day. Exiting...
Looking at the results, we can see that fierce indicated that this setting is a misconfiguration, which should be yet another indicator that allowing AXFR to be opened is not advisable under any circumstance.
If we already have an idea of what we would like to check for, or we have a word list that may be more appropriate as we understand the naming convention of the site being tested, then making a custom word list is recommended:
- Open up nano using
nano myWordList.txt. - Type the following:
irc mail mail1 testmachine1 testmachine www www1 ns
- Press Ctrl + O and Enter to accept writing the file out to
myWordList.txt. - Press Ctrl + X to exit back to the terminal shell.
Now that we created our custom word list named myWordList.txt, let's give it a try:
# fierce -dns example.com -wordlist myWordList.txt
After a short delay we will be presented with the following output:
DNS Servers for example.com: ns14.zoneedit.com ns16.zoneedit.com Trying zone transfer first... Testing ns14.zoneedit.com Request timed out or transfer not allowed. Testing ns16.zoneedit.com Request timed out or transfer not allowed. Unsuccessful in zone transfer (it was worth a shot) Okay, trying the good old fashioned way... brute force Checking for wildcard DNS... Nope. Good. Now performing 9 test(s)... 192.168.1.1 irc.example.com 192.168.1.1 mail1.example.com 192.168.1.1 testmachine.example.com 192.168.1.1 www.example.com 192.168.1.1 .example.com Subnets found (may want to probe here using nmap or unicornscan): 192.168.1.1-255 : 5 hostnames found. Done with Fierce scan: http://ha.ckers.org/fierce/ Found 5 entries. Have a nice day.
Although this server no longer allowed us to use zone transfers, we were still able to map several of the subdomains through the use of a good word list.
When you are unable to perform a zone transfer, there are still methods that can be used to effectively enumerate the subdomains and hostnames on a network. An internal DNS nameserver will be able to provide you with a tremendous amount of information that can later be used to evaluate the network for vulnerabilities, and can ultimately be used to exploit the environment. The fierce tool is a very useful addition to our arsenal of penetration testing utilities, and can be used to accomplish a great deal more than simple DNS brute-forcing.