Skip to content

Recon Part 2 – Fierce, nslookup, and dig


Fierce is a DNS brute-force scanner which comes bundled with the Kali Linux distro. Since we’re not using Kali let’s get and configure fierce from the github project’s page:

First, let’s create a ‘Recon’ folder where we will put our tools. Now that we’ve created our recon folder, let’s get this cloned over. Make sure you’ve installed git (apt-get install git, for instance). Run the following from your ‘recon’ folder to clone the fierce repository there.

git clone

After you have cloned it navigating inside. There will be a perl script we want to make executable so do the following:

chmod +x

Now you can run fierce from the commandline.

Before we run in to any scans, lets look at what this tool can do by first running a -h on it:

abraxas@AttackVM:~/recon/fierce-domain-scanner$ perl -h (C) Copywrite 2006,2007 - By RSnake at

        Usage: perl [-dns] [OPTIONS]

        Fierce is a semi-lightweight scanner that helps locate non-contiguous
        IP space and hostnames against specified domains.  It's really meant
        as a pre-cursor to nmap, unicornscan, nessus, nikto, etc, since all
        of those require that you already know what IP space you are looking
        for.  This does not perform exploitation and does not scan the whole
        internet indiscriminately.  It is meant specifically to locate likely
        targets both inside and outside a corporate network.  Because it uses
        DNS primarily you will often find mis-configured networks that leak
        internal address space. That's especially useful in targeted malware.

        -connect        Attempt to make http connections to any non RFC1918
                (public) addresses.  This will output the return headers but
                be warned, this could take a long time against a company with
                many targets, depending on network/machine lag.  I wouldn't
                recommend doing this unless it's a small company or you have a
                lot of free time on your hands (could take hours-days).
                Inside the file specified the text "Host:\n" will be replaced
                by the host specified. Usage:

        perl -dns -connect headers.txt

        -delay          The number of seconds to wait between lookups.
        -dns            The domain you would like scanned.
        -dnsfile        Use DNS servers provided by a file (one per line) for
                reverse lookups (brute force).
        -dnsserver      Use a particular DNS server for reverse lookups
                (probably should be the DNS server of the target).  Fierce
                uses your DNS server for the initial SOA query and then uses
                the target's DNS server for all additional queries by default.
        -file           A file you would like to output to be logged to.
        -fulloutput     When combined with -connect this will output everything
                the webserver sends back, not just the HTTP headers.
        -help           This screen.
        -nopattern      Don't use a search pattern when looking for nearby
                hosts.  Instead dump everything.  This is really noisy but
                is useful for finding other domains that spammers might be
                using.  It will also give you lots of false positives,
                especially on large domains.
        -range          Scan an internal IP range (must be combined with
                -dnsserver).  Note, that this does not support a pattern
                and will simply output anything it finds.  Usage:

        perl -range 111.222.333.0-255 -dnsserver

        -search         Search list.  When fierce attempts to traverse up and
                down ipspace it may encounter other servers within other
                domains that may belong to the same company.  If you supply a
                comma delimited list to fierce it will report anything found.
                This is especially useful if the corporate servers are named
                different from the public facing website.  Usage:

        perl -dns -search corpcompany,blahcompany

                Note that using search could also greatly expand the number of
                hosts found, as it will continue to traverse once it locates
                servers that you specified in your search list.  The more the
        -suppress       Suppress all TTY output (when combined with -file).
        -tcptimeout     Specify a different timeout (default 10 seconds).  You
                may want to increase this if the DNS server you are querying
                is slow or has a lot of network lag.
        -threads  Specify how many threads to use while scanning (default
          is single threaded).
        -traverse       Specify a number of IPs above and below whatever IP you
                have found to look for nearby IPs.  Default is 5 above and
                below.  Traverse will not move into other C blocks.
        -version        Output the version number.
        -wide           Scan the entire class C after finding any matching
                hostnames in that class C.  This generates a lot more traffic
                but can uncover a lot more information.
        -wordlist       Use a seperate wordlist (one word per line).  Usage:

        perl -dns -wordlist dictionary.txt

As can be seen, we’ve got a good set of options to test out! Before testing, let’s look at what fierce does with a typical scan:

  1. Attempt to do a zone transfer of target domain. This usually will not work and, if it does, it’s usually because of a misconfiguration. If successful, it will present all configured subdomains for the target DNS domain. If not, fierce will move to step 2.
  2. Start brute force scan against target domain. This will use either the builtin or a manually specified wordlist and request dns information for each subdomain tried from that list.
  3. If a subdomain receives a dns response, report a hit and the IP it resolves to.
  4. Once the scan completes, report interesting subnets related to the hits.

Using Fierce – Part 1

Let’s start by doing a basic scan with no extra options and try it against a beloved nerd site, XKCD, the command we will use is: perl -dns -threads 4

This scan will use the builtin subdomain wordlist and check each option against, here’s the first part of our scan output:

abraxas@AttackVM:~/recon/fierce-domain-scanner$ perl -dns -threads 4
DNS Servers for

Trying zone transfer first...
                Request timed out or transfer not allowed.
                Request timed out or transfer not allowed.
                Request timed out or transfer not allowed.
                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.

This is phase one of the scan. It first determined the primary name servers for XKCD (this is often owned by 3rd parties and not the target itself, your DNS queries will often terminate against these). It then attempts zone transfers against those servers; this rarely works but it is great when it does. Once those steps are done the final check is for a wildcard A record, this record, if it exists, will resolve any subdomain not manually specified to an IP address. For those not familiar, here’s a sample set of DNS A records for a site:


*       A     a.b.c.d
www     A     a.b.c.e
dev     A     a.b.c.f

If these records existed for a site called here is how the IP resolutions would work out:   resolves to IP a.b.c.e      resolves to IP a.b.c.f   resolves to IP a.b.c.d

The reason ‘temp’ resolves to a.b.c.d is because in DNS a value of ‘*’ (also known as a wildcard record) means ‘unless otherwise specified in DNS, resolve a subdomain to this IP address. This type of record mostly defeats brute-forcing subdomains because each record would return a value so it would look like each entry exists. However, by doing looking for different values you can still potentially extract valuable information. In the previous example the fact that ‘,,’ all resolve to a.b.c.d while ‘’ resolves to a.b.c.f might indicate that a.b.c.f is a legitimate subdomain while the others may or may not be.

Using Fierce – Part 2

Now we’ll take a look at the second part of this scan:

Now performing 1594 test(s)...

So this scan found 11 entries from the 1594 words we checked. Some of them have multiple entries because of load-balancing, misconfigurations, or other reasons. Despite most of these being related to mobile one of these provides us with a ton of information! I decided to check out to see what was there, this is what came up:

[] (segment 1 character 1): 
unexpected end of input
expecting stream, xb, redirect, test, comic, random, api-0, event, graph, csrf, login, turtle, cdndata, whatif or thing-explainer

At a glance it looks like some of these could be subdomains which fierce didn’t detect, this leads us to a few other utilities of use, dig and nslookup. Remember that fierce is using a wordlist and that unless the subdomain is on the wordlist, it will not be detected. Always be looking to improve your wordlists and keep in mind that the more items on the list, the longer it takes to scan.

The dig command is primarily used to query DNS servers and nslookup does forward and reverse DNS lookups. We’ll start with nslookup as it is a bit simpler to use:

abraxas@AttackVM:~/recon/fierce-domain-scanner$ nslookup

** server can't find NXDOMAIN

Non-authoritative answer: canonical name =        canonical name =    canonical name =

This snippet shows launching the nslookup utility, checking  the subdomain, getting no result, checking the subdomain, getting a CN and A record response.


** server can't find NXDOMAIN

This first part indicates the server queried and the port it was queried on (53 which is the standard for DNS). The last line indicates there was not a successful lookup for

The second attempt is successful and here’s the breakdown:


Non-authoritative answer: canonical name =        canonical name =    canonical name =

The queried server and port remains the same, which is to be expected and then we get a few lines:

canonical name refers to a CNAME record which is, essentially, a redirect. In this case if a query comes in for it redirects that request to There are then two more CNAME records which ultimately land the request at which is at IP as seen by the last A record.

NSLookup also has a verbose mode which shows a more comprehensive conversation. To enter this mode, after launch nslookup type set d2 and then input your query. Here’s the result from

abraxas@AttackVM:~/recon/fierce-domain-scanner$ nslookup                                                       
> set d2                                                                                                       
looking up                                                                                     
resetting lookup counter.                                                                                      
cloning server list                                                                                            
using root origin                                                                                              
recursive query                                                                                                
starting to render the message                                                                                 
done rendering                                                                                                 
create query 0x7f5ce3a95018 linked to lookup 0x7f5cd8010ce8                                                    
have local timeout of 5                                                                                        
working on lookup 0x7f5cd8010ce8, query 0x7f5ce3a95018                                                         
recving with lookup=0x7f5cd8010ce8, query=0x7f5ce3a95018, sock=0x7f5ce3a97010                                  
sending a request                                                                                              
lock_lookup ../../../bin/dig/dighost.c:2659                                                                    
list empty                                                                                                     
unlock_lookup ../../../bin/dig/dighost.c:2690                                                                  
lock_lookup ../../../bin/dig/dighost.c:3533                                                                    
lookup=0x7f5cd8010ce8, query=0x7f5ce3a95018                                                                    
before parse starts                                                                                            
after parse                                                                                                    
Non-authoritative answer:                                                                                      
printsection()                                                                                         canonical name =                                                            canonical name =                                    canonical name =                               
still pending.                                                                                                 
list empty                                                                                                     
freeing server 0x7f5cd80008c8 belonging to 0x7f5cd8010ce8                                                      
list empty                                                                                                     
shutting down                                                                                                  
unlock_lookup ../../../bin/dig/dighost.c:4046

I highly recommend getting to know nslookup – it is available by default in most Windows, Linux, and OSX systems.

The second tool, which does a very similar thing, is called dig. Here’s what it looks like:

abraxas@AttackVM:~/recon/fierce-domain-scanner$ dig

; <<>> DiG 9.10.3-P4-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43458
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1280
;               IN      A

;; ANSWER SECTION:        3496    IN      CNAME       3496    IN      CNAME 3496 IN   CNAME 30 IN   A

;; Query time: 3 msec
;; WHEN: Sun Aug 14 21:30:39 UTC 2016
;; MSG SIZE  rcvd: 165

As you can see in the ‘Answer’ section the results are similar to what we found in nslookup and contain some extra information like the TTL for the records. Get to know these tools.

Using Fierce – Part 3

Lastly, going back to fierce, let’s examine the last section of the output:

Subnets found (may want to probe here using nmap or unicornscan):                : 2 hostnames found.                                    : 2 hostnames found.                                    : 1 hostnames found.                                   : 2 hostnames found.                                      : 2 hostnames found.                                     : 2 hostnames found.                                     
Done with Fierce scan:                               
Found 11 entries.                                                                
Have a nice day.

After returning the IPs we receive some useful data about the networks the results came in on. Were you doing a pentest for a company this might give you an idea of where their public IP space is and could warrant investigating nearby IPs for content with unexpected DNS names or which may only be using the IP address without DNS names, it is not uncommon to see this.

Using Fierce – Part 4

Many of the options in Fierce are useful and I just wanted to include an overview of a few of them here.

  1.  wordlist – this flag will let you point to a wordlist file which is a line-separated file of words to test for subdomains. There are some great files out there which I recommend searching for to use in place of the builtin hosts.txt file that comes with fierce
  2. connect – This will attempt to make an http connection to each of the tested subdomains and returns the headers.
  3. delay – this specifies a delay, in seconds, to wait between queries
  4. dnsserver – choose specific dns server(s) to query through
  5. file – output the results to a file

What are you favorite custom scans?

The next post will cover a few more recon tools such as gobuster, eyewitness, and metagoofil! As always, comments and criticisms are appreciated!

Next post is up: Gobuster and EyeWitness

Leave a Reply

Your email address will not be published. Required fields are marked *