In this tutorial, we’ll look at DNSEnum. The author describes it as a DNS enumeration tool, which performs several functions including gathering the host’s A records, MX records, attempting zone transfers, and brute forcing subdomains. Each of these functions can give you quite a bit of information about the target. Remember, the more information you can gather upfront during a test, the better prepared you will be to create an appropriate attack against your target.
HOW TO USE
There are a couple of different ways you can launch the tool. The first is to go to “Applications –> Information Gathering –> DNS Analysis”, and click on DNSEnum. You can also open a terminal, and type “dnsenum” at the prompt.
Launching the tool without specifying any parameters will simply list the available switches. I won’t be covering all of them here, but will go over the most common ones used during a pen-test. We’ll start at the top of the list, and work our way down.
1. — dnsserver: Use this DNS server for A, NS, and MX queries.
By default, if you don’t use this switch, and just type in “dnsenum target.com”, the queries will use your default resolving server, which in most cases is located at your ISP. Using this switch allows you to specify another resolving server, i.e. Google’s public name server, to perform queries against. The command would look like this:
dnsenum — dnsserver 220.127.116.11 target.com
You can run the tool both ways to see if the results vary at all. So, why would you want to do this? It’s possible one of the DNS servers you hit has stale entries, meaning, it doesn’t contain the most up-to-date information for a particular domain. By comparing the results from both runs of the tool, you may be able to pick up on additional zone entries that the company may not have intended to be public.
2. — enum: This is a shortcut switch, which actually contains 3 different switches. They are “–threads”, which is set to 5, “-s”, which is the maximum number of subdomains that will be scraped from Google, and “-w”, which tells it to perform a whois query on Class C network ranges.
**Note – The Google scraping feature can be hit or miss. Google considers automated scraping to be a violation of their TOS, and blocks access if you try too many requests.
You can always perform this piece manually by going to Google, and using the “allinurl:-www site:target.com” advanced search feature, which is what dnsenum is using anyway.**
3. –noreverse: This will bypass the reverse lookup operation. If you’re performing reverse lookups on a Class C netrange, the amount of lookups could be huge, and take quite a long time. I normally don’t use reverse lookups with dnsenum for this reason.
4. –subfile: You can use this switch to create a file which will contain any new subdomains that were discovered. If you don’t use this switch, the results just get output to the screen. Type the switch, then follow it with the path to where you want to save the file. I will normally create a folder on the desktop named for the target company. It makes it easier to find everything for a specific test, if you have it all stored in one location.
5. -f: You’ll need to use this switch to specify the location of the pre-defined wordlist containing the subdomains you’re searching for. DNSEnum has a list you can use located under /usr/share/dnsenum/dns.txt.
These are the switches I would use with this tool. You can read the help file for explanations of the others. Everything there is pretty self-explanatory.
Now that we’ve gone over the switches, let’s take a look at them in action, and see what kind of results DNSEnum will give us.
RUNNING THE TOOL
Here is an example command line configuration you can use with DNSEnum:
dnsenum –dnsserver 18.104.22.168 –enum –noreverse -f /usr/share/dnsenum/dns.txt –subfile ~/Desktop/hackthissite/hts.txt
Here it is in action:
The output you get is formatted nicely into different sections, which makes it easy for us to find specific information.
So, what are some of the more interesting bits here? Under “Name Servers” we can see they’re using a third-party company, “buddyns.com” which is used as a secondary DNS service, and under “Mail Servers”, it appears they’re using Gmail.
Looking at the next section, the attempt to perform a zone transfer failed, which is pretty common today, but still something to check for on a test. Below, I’ll show another site that is configured to allow zone transfers, so you can see the type of information that can be discovered using this technique.
Next, we have the results of the Google Scraping function. It lists subdomains which Google knows about. We see that it found the subdomains “speedtest”, and “forums”.
Here, we have the results of the subdomain brute forcing function. Notice the additional systems it found – admin, irc, and mail. These are systems we can attack that may provide an easier entrance into the target. Sometimes, administrators have systems set up, maybe like a test server, or development server, which have security holes. The admins don’t intend for these systems to be seen by the public, so they don’t really consider them to be a security risk. One thing to note is, if you discover additional systems on a test, be sure to verify with the client that these systems are within scope for the test. You don’t want to attack something that could be a critical production server, and end up causing major issues for the client.
The last section here shows the results of the whois query, and the associated IP blocks for the domain.
Robin Wood of Digi Ninja, has configured a website that allows zone transfers. The site is http://zonetransfer.me. We can use this site to run our tools against, and see the information that can be gathered from a zone transfer.
We’ll again run DNSEnum, and specify the domain’s authoritative name server to run the queries against.
dnsenum –dnsserver nsztm1.digi.ninja –noreverse -f /usr/share/dnsenum/dns.txt –subfile ~/Desktop/zonetransferme/ztf.txt zonetransfer.me
Here is the zone information for the domain:
As you can see, there’s a ton of information you can get from a zone transfer. It can quickly give insight into the layout of the internal network, as well as provide other information that can be used in social engineering attacks, and client-side attacks.
I wanted to highlight some of the DNS resource record types here, and give a brief explanation of what they are.
1. SOA – At the top, we have the SOA record, which is the Start of Authority. Every zone file will have this entry, which shows what the primary DNS server is for the domain. Other items normally here are the email address of the domain administrator, a serial number used by the secondary DNS servers to see if the zone information has changed, and refresh and expire intervals. We see here that the primary DNS server is nsztm1.digi.ninja.
2. HINFO – HINFO is a record that will list the host server’s operating system type. I believe this one has been spoofed. :-) Can that calculator really host a domain?
3. TXT – TXT records normally just contain some kind of descriptive text. Some admins may put things here like contact names, and phone numbers. This entry shows that the site has been verified by Google to use in an app
4. MX – MX records show the email servers in use. We see here that the site is using Gmail
5. A – A records show the mapping of the domain to the IP address. The entries here are the same as what you would see in a Windows hosts file.
6. NS – NS records show which DNS servers are authoritative for a zone. These should be the primary and secondary DNS servers for a domain.
7. SRV – Service records show the location of a service. They are normally used in connection with directory servers like LDAP, or Windows directory services. In this entry, we see SIP being used, which is a protocol for VOIP phones.
8. PTR – Pointer records are used for reverse lookups, meaning it maps an IP address to a domain name, just the opposite of an A record. Reverse lookups are mainly used as a way to track where website visitors came from, or the origination of an email message. Email servers are most often configured to perform reverse lookups.
9. AFSDB – This is an old resource record type, and should be replaced by an SRV record. You really shouldn’t come across these on any modern servers. The machines they would reference could be Authentication servers, Volume Location servers, and a couple other types. Here it looks like there is an authentication and volume server referenced.
10. AAAA – These are the same as A records, only they use the IPv6 format for IP addresses.
11. LOC – Location records specify geographical information about hosts using latitudes and longtitudes. Just in case you’re interested, the coordinates here point to the city of Derbyshire in England.
12. NAPTR – This is the “Name Authority Pointer” record. It’s mainly used for internet telephony. It maps servers and user addresses, or telephone numbers to be routed over the internet
13. RP – This record specifies the mailbox of the person responsible for the domain.
I highlighted these, because they are unique DNS record types found here. If you look through the entire zone file, you’ll see some pretty interesting entries, with information that could be useful in planning an attack. We have email addresses, phone numbers, and names of individuals, and all this could be used in social engineering attacks, or client side attacks.
Be sure to keep track of all the information you gather from each phase of a pentest. Things that may not seem important at the time, could be a key for later attacks.
Check out the YouTube video I created for this tutorial: