Fierce
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:
abraxas@AttackVM:~/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:
abraxas@AttackVM:~/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:
Name-Type-Value
* 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)... 107.6.98.34 c.xkcd.com 107.6.98.34 dynamic.xkcd.com 104.196.146.194 forums.xkcd.com 23.235.37.67 m.xkcd.com 23.235.37.67 mobile.xkcd.com 104.156.81.67 m.xkcd.com 104.156.81.67 mobile.xkcd.com 104.156.85.67 mobile.xkcd.com 104.156.85.67 m.xkcd.com 23.235.33.67 m.xkcd.com 23.235.33.67 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:
abraxas@AttackVM:~/recon/fierce-domain-scanner$ nslookup > comic.xkcd.com Server: 168.63.129.16 Address: 168.63.129.16#53 ** server can't find comic.xkcd.com: NXDOMAIN > whatif.xkcd.com Server: 168.63.129.16 Address: 168.63.129.16#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: 151.101.40.67
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: 168.63.129.16 Address: 168.63.129.16#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: 168.63.129.16 Address: 168.63.129.16#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: 151.101.40.67
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 151.101.40.67 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:
abraxas@AttackVM:~/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(168.63.129.16)
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: 168.63.129.16
Address: 168.63.129.16#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: 151.101.40.67
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:
abraxas@AttackVM:~/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 151.101.40.67 ;; Query time: 3 msec ;; SERVER: 168.63.129.16#53(168.63.129.16) ;; 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):
104.156.81.0-255 : 2 hostnames found.
104.156.85.0-255 : 2 hostnames found.
104.196.146.0-255 : 1 hostnames found.
107.6.98.0-255 : 2 hostnames found.
23.235.33.0-255 : 2 hostnames found.
23.235.37.0-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 builtinhosts.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 queriesdnsserver– choose specific dns server(s) to query throughfile– 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