Information gathering from DNS records
In this post we will use some popular tools to see how basic DNS queries work. We’ll be looking at the different record types and how to pull them from a DNS server.
Step 1: Finding Name Servers
When you look up websites like google.com, your computer sends a DNS request to some DNS server somewhere and asks for the IP address of google.com. In a real enterprise, this DNS server might contain thousands of records that represent each device on the corporate network. Let’s look at some ways to pull the most useful DNS record types on real examples.
When querying servers for real organizations, such as Yahoo or Facebook, we would first have to try and find which DNS servers on the internet we need to query. To do this we can use dig. On your terminal enter the following:
Note: skillsetlocal.com is not a live website, it's a locally hosted website.
dig @127.0.0.1 skillsetlocal.com ns
This query will return the list of DNS servers. You will see them in the “ANSWER SECTION”.
Step 2: Finding mail Servers
We will now try to query our DNS server for MX records related to the skillsetlocal.com domain. Enter the following command to do that:
dig @127.0.0.1 skillsetlocal.com mx
Step 3: DNS Zone Transfer
So far we have been pulling specific types of records from our DNS server. What if we wanted to pull all records? For this, we can attempt the AXFR query (also known as DNS zone transfer). AXFR is used to replicate DNS databases, and a successful query can provide us with lots of useful information about the target network. We can use dig for AXFR queries as well. Issue the following command to pull all DNS records from our server:
dig @127.0.0.1 skillsetlocal.com axfr
As you can see, we discovered several subdomains with corresponding IP addresses, thus expanding our knowledge about the target network.
Step 4: Reverse Lookup
Everything we have done so far depends on getting data from the DNS servers’ forward lookup records. In other words, these DNS files allow us to look up a host by name, such as www.yahoo.com. Essentially, www is a host on the yahoo.com domain. Sometimes DNS servers also store reverse lookup records. With reverse lookup records we can do the opposite, which tells us which hosts are associated with a given IP address.
The tool we’ll be using to do reverse lookups is named DNSrecon. Let's run it on the class C network using the IP addresses we discovered in the previous step with our DNS zone transfer. The -n option specifies the name (domain) server, and -r stands for "range".
dnsrecon -n skillsetlocal.com -r 192.168.1.1-192.168.1.254
In the output, you should see the list of host names associated with IPs within this range.
Step 5: Grepping DNSrecon Output
In most cases, when used against real networks, dnsrecon will produce a lot of output. Trying to process a lot of data as it comes is difficult. To make this task easier, we can write output to a file or combine dnsrecon commands with our good friends more and grep. Let's run dnsrecon again, but this time looking specifically for payroll servers:
dnsrecon -n skillsetlocal.com -r 192.168.1.1-192.168.1.254 | grep payroll
Step 6: Starting DNSChef
So far we've been practicing gathering various types of information contained in DNS records. In the next two steps, we will see how DNS can be used in attacks as well. We will use a Python-based tool DNSChef. It is a highly configurable DNS proxy, which allows intercepting and redirecting DNS queries. In a real penetration test, you would need to either manually configure or poison DNS server entry to point to DNSChef.
The use of DNS Proxy is recommended in situations where it is not possible to force an application to use some other proxy server directly. For example, some mobile applications completely ignore OS HTTP Proxy settings. In these cases, the use of a DNS proxy server such as DNSChef will allow you to trick that application into forwarding connections to the desired destination.
Without any parameters specified, DNSChef will run in "full proxy" mode, forwarding all requests to an upstream DNS server (18.104.22.168 by default) and returning them back to the querying host. This is useful if we wanted to capture and examine DNS query packets. However, we can also use DNSChef to actually send intercepted queries to a specified IP. We will need to specify an interface for DNSChef that is different from our 127.0.0.1 nameserver IP. The following command will send all DNS queries for google.com to 22.214.171.124:
sudo dnschef --interface=127.0.0.2 --fakeip=126.96.36.199 --fakedomains=google.com
Step 7: Migrating Tabs
Now let's see if our chef's cooking is any good. Migrate tabs by command as Ctrl + Shift + T.
Step 8: DNSChef is Cooking
Let's run the dig command on google.com using our DNSChef proxy IP address as the nameserver. Enter the following command:
dig @127.0.0.2 google.com
You can see that the A record for google.com is pointing to 188.8.131.52.
If you try running the same dig command against any other domain it won't return any results.
Now switch tabs again and let's see the update in first tab.
Step 9: Examining DNSChef Output
You will see that DNSChef had captured the query for google.com and cooked up a response with the fake IP that we specified.
Hit Ctrl+C to shut down DNSChef.
Also Read: How to prevent identity theft
That's it for this post hope you like it and subscribe to our blog for more amazing things like this in future.