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: https://github.com/davidpepper/fierce-domain-scanner
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 https://github.com/davidpepper/fierce-domain-scanner
After you have cloned it navigating inside. There will be a fierce.pl perl script we want to make executable so do the following:
chmod +x fierce.pl
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:
[email protected]:~/recon/fierce-domain-scanner$ perl fierce.pl -h fierce.pl (C) Copywrite 2006,2007 - By RSnake at http://ha.ckers.org/fierce/ Usage: perl fierce.pl [-dns example.com] [OPTIONS] Overview: 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. Options: -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 fierce.pl -dns example.com -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 fierce.pl -range 111.222.333.0-255 -dnsserver ns1.example.co -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 fierce.pl -dns examplecompany.com -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 better. -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 fierce.pl -dns examplecompany.com -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:
- 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.
- 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.
- If a subdomain receives a dns response, report a hit and the IP it resolves to.
- 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 fierce.pl -dns xkcd.com -threads 4
This scan will use the builtin subdomain wordlist and check each option against xkcd.com, here’s the first part of our scan output:
[email protected]:~/recon/fierce-domain-scanner$ perl fierce.pl -dns xkcd.com -threads 4 DNS Servers for xkcd.com: dns1.p03.nsone.net dns2.p03.nsone.net dns3.p03.nsone.net dns4.p03.nsone.net Trying zone transfer first... Testing dns1.p03.nsone.net Request timed out or transfer not allowed. Testing dns2.p03.nsone.net Request timed out or transfer not allowed. Testing dns3.p03.nsone.net Request timed out or transfer not allowed. Testing dns4.p03.nsone.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.
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
example.com here is how the IP resolutions would work out:
www.example.com resolves to IP a.b.c.e
dev.example.com resolves to IP a.b.c.f
temp.example.com 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 ‘a.example.com, b.example.com, c.example.com’ all resolve to a.b.c.d while ‘dev.example.com’ 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)... 22.214.171.124 c.xkcd.com 126.96.36.199 dynamic.xkcd.com 188.8.131.52 forums.xkcd.com 184.108.40.206 m.xkcd.com 220.127.116.11 mobile.xkcd.com 18.104.22.168 m.xkcd.com 22.214.171.124 mobile.xkcd.com 126.96.36.199 mobile.xkcd.com 188.8.131.52 m.xkcd.com 184.108.40.206 m.xkcd.com 220.127.116.11 mobile.xkcd.com
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 c.xkcd.com 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:
[email protected]:~/recon/fierce-domain-scanner$ nslookup > comic.xkcd.com Server: 18.104.22.168 Address: 22.214.171.124#53 ** server can't find comic.xkcd.com: NXDOMAIN > whatif.xkcd.com Server: 126.96.36.199 Address: 188.8.131.52#53 Non-authoritative answer: whatif.xkcd.com canonical name = what-if.xkcd.com. what-if.xkcd.com canonical name = prod.i.ssl.global.fastly.net. prod.i.ssl.global.fastly.net canonical name = prod.i.ssl.global.fastlylb.net. Name: prod.i.ssl.global.fastlylb.net Address: 184.108.40.206
This snippet shows launching the
nslookup utility, checking the comic.xkcd.com subdomain, getting no result, checking the whatif.xkcd.com subdomain, getting a CN and A record response.
> comic.xkcd.com Server: 220.127.116.11 Address: 18.104.22.168#53 ** server can't find comic.xkcd.com: 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 comic.xkcd.com.
The second attempt is successful and here’s the breakdown:
> whatif.xkcd.com Server: 22.214.171.124 Address: 126.96.36.199#53 Non-authoritative answer: whatif.xkcd.com canonical name = what-if.xkcd.com. what-if.xkcd.com canonical name = prod.i.ssl.global.fastly.net. prod.i.ssl.global.fastly.net canonical name = prod.i.ssl.global.fastlylb.net. Name: prod.i.ssl.global.fastlylb.net Address: 188.8.131.52
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
whatif.xkcd.com it redirects that request to
what-if.xkcd.com There are then two more CNAME records which ultimately land the request at
prod.i.ssl.global.fastlylb.net which is at IP 184.108.40.206 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 whatif.xkcd.com:
[email protected]:~/recon/fierce-domain-scanner$ nslookup > set d2 > whatif.xkcd.com addlookup() make_empty_lookup() looking up whatif.xkcd.com start_lookup() setup_lookup(0x7f5cd8010ce8) resetting lookup counter. cloning server list clone_server_list() make_server(220.127.116.11) using root origin recursive query add_question() starting to render the message done rendering create query 0x7f5ce3a95018 linked to lookup 0x7f5cd8010ce8 do_lookup() send_udp(0x7f5ce3a95018) bringup_timer() have local timeout of 5 working on lookup 0x7f5cd8010ce8, query 0x7f5ce3a95018 sockcount=1 recving with lookup=0x7f5cd8010ce8, query=0x7f5ce3a95018, sock=0x7f5ce3a97010 recvcount=1 sending a request lock_lookup ../../../bin/dig/dighost.c:2659 success send_done() sendcount=0 check_if_done() list empty unlock_lookup ../../../bin/dig/dighost.c:2690 recv_done() lock_lookup ../../../bin/dig/dighost.c:3533 success recvcount=0 lookup=0x7f5cd8010ce8, query=0x7f5ce3a95018 before parse starts after parse printmessage() Server: 18.104.22.168 Address: 22.214.171.124#53 Non-authoritative answer: printsection() whatif.xkcd.com canonical name = what-if.xkcd.com. what-if.xkcd.com canonical name = prod.i.ssl.global.fastly.net. prod.i.ssl.global.fastly.net canonical name = prod.i.ssl.global.fastlylb.net. Name: prod.i.ssl.global.fastlylb.net Address: 126.96.36.199 still pending. cancel_lookup() check_if_done() list empty clear_query(0x7f5ce3a95018) sockcount=0 check_next_lookup(0x7f5cd8010ce8) try_clear_lookup(0x7f5cd8010ce8) destroy freeing server 0x7f5cd80008c8 belonging to 0x7f5cd8010ce8 start_lookup() check_if_done() list empty shutting down dighost_shutdown() 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:
[email protected]:~/recon/fierce-domain-scanner$ dig whatif.xkcd.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> whatif.xkcd.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43458 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;whatif.xkcd.com. IN A ;; ANSWER SECTION: whatif.xkcd.com. 3496 IN CNAME what-if.xkcd.com. what-if.xkcd.com. 3496 IN CNAME prod.i.ssl.global.fastly.net. prod.i.ssl.global.fastly.net. 3496 IN CNAME prod.i.ssl.global.fastlylb.net. prod.i.ssl.global.fastlylb.net. 30 IN A 188.8.131.52 ;; Query time: 3 msec ;; SERVER: 184.108.40.206#53(220.127.116.11) ;; 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): 18.104.22.168-255 : 2 hostnames found. 22.214.171.124-255 : 2 hostnames found. 126.96.36.199-255 : 1 hostnames found. 188.8.131.52-255 : 2 hostnames found. 184.108.40.206-255 : 2 hostnames found. 220.127.116.11-255 : 2 hostnames found. Done with Fierce scan: http://ha.ckers.org/fierce/ 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.
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.txtfile that comes with fierce
connect– This will attempt to make an http connection to each of the tested subdomains and returns the headers.
delay– this specifies a delay, in seconds, to wait between queries
dnsserver– choose specific dns server(s) to query through
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