DNS recon
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 on 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 nameservers. An example of the information you are able to gather includes:
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 — it's there when you need it
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. nslookup is cross-platform, and will be found preinstalled on most operating systems.
Note
During the following examples we have 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 have 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 domain name example.com we enter the following into a BackTrack 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™. #53 UDP is the port being used when making the request. The preceding example output would indicate that example.com resolves to 127.1.72.107.
Results can be validated by 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 nameserver 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@bt:~# 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 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 set type=ns.
Once the variables have been set, we can query as 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@bt:~# nslookup -type=ns example.com 156.154.70.22
We have 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.
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 be rest assured that this is one tool that you will have available by default. As nslookup can be run from a single command-line prompt you can easily create a script that automates the task of extracting information about many domain or hostnames, then have the output placed into a text file.
- In BackTrack, open a terminal session and type
nano AutoM8and 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 "Gettingname 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 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 the output similar to the following format:
root@bt:~# ./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 have validated this by 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, but 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.
What did we learn?
If you take a look at the output of the various examples you should note that we 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 have also validated that the domain names we have resolve 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)
Domain Information Groper (Dig) is a powerful alternative to nslookup. It has the capability to run either 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 BackTrack type dig example.com from the terminal command line. Here is an example of this command when run on a domain that is owned by the author.
root@bt:~# dig example.com
; <<>> DiG 9.7.0-P1 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56376
;; flags: qr rd ra; 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, if there were any errors, and of course that the A record for example.com contains 10.1.1.1. We 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 SOA ns2.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 it gives an attacker a wealth of data in regards to hostnames and other information. We will now review the steps necessary to perform a zone transfer on the domain example.com. 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 BackTrack terminal window.
- Type the following and press Enter:
# dig @ns1.example.com example.com axfr - Review the results:
; <<>> DiG 9.7.0-P1 <<>> @ns1.example.com example.com axfr ; (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 nameserver 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:
; <<>> DiG 9.7.0-P1 <<>> @ns16.zoneedit.com example.com axfr ; (1 server found) ;; global options: +cmd example.com. 7200 IN SOA ns16.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 SOA ns16.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 trivial 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 I highly suggest that you take a look at zonetransfer.me which will redirect you to http://www.digininja.org/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.
+answer can be toggled to display only the answer section.
root@bt:~# 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 have determined that this particular nameserver 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 (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 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 TXT file using the nano text editor included in BackTrack. Open up a terminal shell in BackTrack and type
nano 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 save the file.
- Press Ctrl + X to exit back to the terminal.
- Invoke the dig command using:
# 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.
DNS brute forcing with fierce
In a secured environment DNS brute forcing is likely to be your best bet in determining which hosts are used in non-contiguous IP space. BackTrack 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 BackTrack we will open up a terminal session and change directory to where the fierce.pl perl script is located:
# cd /pentest/enumeration/dns/fierce
fierce.pl contains a help section that can be accessed using:
# ./fierce.pl -h
The most basic method of using fierce is to use:
# ./fierce.pl -dns example.com
This will result in 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 we have learned previously, zone transfers will extract all known domain information from the server with one command. There would 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 if 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 /fierce directory on Backtrack will be used by default.
Here fierce.pl is used against a domain that allows for zone transfers:
# ./fierce.pl -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 SOA ns16.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.pl indicated that this setting is a misconfiguration which should be yet another indicator that allowing open AXFR 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 press Enter to accept writing the file out to
myWordList.txt. - Press Ctrl + X to exit back to the terminal shell.
Now that we have created our custom word list named myWordList.txt, let's give it a try:
# ./fierce.pl 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 ultimately be used to exploit the environment. fierce.pl 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.