5 Tips for Threat Hunting with Farsight DNSDB
Introduction
Threat hunting teams go out and look for trouble, focusing on being proactive rather than the more traditional security model of reacting to alerts. In this blog article, I’ll cover some of my approaches to threat hunting using Farsight’s DNSDB. The queries below can be scripted via the API or manually run in the web interface. You don’t need to be a full-time hunter to make use of these techniques — incident responders will also find them just as useful when trying to reactively understand a threat on their network.
Tip 1: Uncover new threats from a single domain
After coming across an interesting Fully Qualified Domain Name (FQDN), one of the first things I’ll do is an RDATA query to check what other FQDN’s point to or have pointed to, that same IP address. A query like:
API: /lookup/rdata/ip/$ip_address
This query gives us a list of A or AAAA DNS records that point to that same IP address. If the time-stamps span the same range, it can be assumed that these hostnames are behind the same network asset. They might be on the same server, but they could just as easily be behind a load-balancer. If you are searching for a phishing site, and the other records returned are clearly also phishing, you have a good idea what this system is about.
Tip 2: Check out the digital neighborhood
If your single IP pivot didn’t provide many results, you can step back and look at the larger net-block. I tend to do this task in steps. First, I’ll look at the /28 and move towards the /24. The query is similar to what I showed in Tip 1, except that the slash in CIDR notation is replaced with a comma. So, the query would look like:
API: /lookup/rdata/ip/$ip_address,$prefix_length
Note that you aren’t required to change the last octet of the IP address. The CIDR logic in DNSDB will do the right thing and present you with query results for the block of a size you provided with $prefix_length that contains the $1p_address provided. For example, a query for 192.168.5.25/24 will span 192.168.5.0-192.168.5.255.
Looking at larger and larger blocks, you can quickly establish if the address in question is on a typical hosting site, a dynamic end-user address space, or if you are looking at a larger-scale phishing or underground operation.
Tip 3. Identify the name servers behind DNS abuse
Domains are easy to acquire inexpensively and anonymously. Reliable authoritative DNS servers are much harder to come by. Looking at the name-servers related to a threat provides a lot of additional information and, often, leverage. If you find that a domain attacking your organization is hosted on a well-known DNS platform, you can bet their abuse team will usually act quickly and decisively on well-formulated abuse reports with plenty of clear evidence of a threat. The query to find a target domain hosted on name servers as ns.1.example.com is simple:
API: /lookup/rdata/name/ns1.example.com
The results will be any records where “ns1.example.com” is the answer section You can take this a step further and query for “ns2.example.com” or even”*example.com.” The latter query is likely to return more than just name-server records, but that can be easily refined by adding a “/NS” to the end of the query, thus limiting the results to only NS records.
Tip 4. Crack the popular phishing method
In the case of phishing, we often see attackers attempt to piggyback the target domain name onto a longer FQDN by appending a base domain so that the target domain is placed at the front of the FQDN. For example, we get $target_domain.$base_domain. Attackers use this technique to amplify their effectiveness by pointing to many target domains leveraging essentially free FQDNs on an existing domain and infrastructure.
To look for these types of domains, I would take an initial phishing example such as: paypal.com.br.incom.pk.
We’ll assume that the target domain in this case is “paypal.com.br”, a common phishing target, but as you will see below, any domain will work. The $base.domain in this case is “incom.pk.” We will use the $base_domain to perform a left-hand wildcard search looking like:
API: /lookup/rrset/*.$base_domain
$ dnsdb_query -r *.org.incom.pk./A |grep IN |awk {'print $1'} | uniq
pk.incom.org
pk.incom.org.b1
pk.incom.org.ja
pk.incom.org.jw
pk.incom.org.kk
pk.incom.org.kp
pk.incom.org.ld
pk.incom.org.rj
pk.incom.org.w3
pk.incom.org.wp
pk.incom.org.0je
pk.incom.org.4-h
pk.incom.org.4ri
pk.incom.org.7ry
pk.incom.org.7si.0f87a7e2c60495d5d40df5399a9d41ee
pk.incom.org.7si.70f4ad65b5efd011e0ad3ca9ada65b26
pk.incom.org.aag
pk.incom.org.aao
pk.incom.org.abi.go
pk.incom.org.acg
pk.incom.org.acm
pk.incom.org.acm.techpolicy
pk.incom.org.adb
pk.incom.org.adw
pk.incom.org.aem
pk.incom.org.aes
pk.incom.org.afi
pk.incom.org.afj
pk.incom.org.aft
pk.incom.org.agc
pk.incom.org.agu
pk.incom.org.aia
pk.incom.org.akc
pk.incom.org.ala
pk.incom.org.alz
pk.incom.org.aoa.sso
...
(The order of the labels in the FQDNs above has been reversed to prevent accidental navigation to possibly malicious links.)
(I added .org to the $base_domain to reduce the size of the result. Then printed a unique list of only the FQDNs.)
The above list is only a fraction of the extensive result, there are many recognizable domains among the noise.
Tip 5. Discover the TLDs you didn’t know existed
Let’s say you have discovered a domain of interest, or you are looking after your own domains. You want to know if anyone has created similar domains based on other TLDs or even other domains. My approach for finding these related assets is to use a right-hand wildcard query. For example, I’ll look for instances of our company domain name, Farsight Security, in all TLDs. With the rapidly growing number of TLDs it is hard for most organizations to keep track of their domain assets.
API: /lookup/rrset/farsight.*/A
$ dnsdb_query -r farsightsecurity.*/A |grep IN |awk {'print $1'} | uniq
uk.co.farsightsecurity
ru.farsightsecurity
com.farsightsecurity
com.detaildomain.com.farsightsecurity
ga.blum.farsightsecurity
com.trapponline.farsightsecurity
(The order of the labels in the FQDNs above has been reversed to prevent accidental navigation to possibly malicious links.)
Conclusion
This article covers just a few of the threat hunting techniques that leverage DNSDB, but there are many others. Every Internet transaction leverages the DNS in one way or another. DNSDB provides unmatched visibility into how the answers to DNS lookups have changed over time —critical information that can be extremely valuable in investigations.
Ben April is a Senior Director for Research for Farsight Security, Inc.
