DNS-Based Threat Intelligence
Are you seeing anomalous volumes of traffic to external domains or IPs that you can’t quantify? Your next steps might include checking third-party threat intelligence web sites for any known data on those hosts, or checking passive DNS for domains affiliated with an IP. Reconnaissance can go further by using DNS-based services to paint a clearer picture of the external host(s) in question.
There are many different services to check IP and domain reputation once you’ve identified a subject to investigate. You may already have scripts and integrations setup to poll external services on-demand using REST APIs. However, simple and accessible recon options are available over the DNS protocol. Some services use DNS Response Policy Zones (RPZ), while other services function as full DNS providers and must be queried directly to see if a domain is blocked or sinkholed. There are different types of information you can gather, including:
- Malicious or suspicious IP addresses and domains
- Known spam-originating and open SMTP relay IP addresses
- Known spam-affiliated email sender domains
- TOR entry & exit node IP addresses
- BOGON (IANA unassigned) IP address ranges
- Zero-reputation domains
- Domain NS records
- Known malicious file hashes, email senders, and crypto wallets
Let’s go over how to query a few of these data sources using DNS.
IP Research using RPZs
There are many services available for querying IP address information. While most of these were originally created to filter spam email, many of them also have information on malware hosting and botnet C2 IPs. For each of these services, the IP address must be reversed and prepended to the DNS zone before querying them. Here are a few examples of DNS zones to query for IP data:
- zen.spamhaus.org – Spamhaus IP block list, which aggregates results from several other Spamhaus services including the Exploit Block List (XBL).
- b.barracudacentral.org – Barrracuda block list keeps track of sources of spam and viruses.
- tor.dan.me.uk – All TOR nodes (entry, exit, transit nodes). Also responds to TXT queries with additional information.
- torexit.dan.me.uk – TOR exit nodes only. Also responds to TXT queries with additional information.
- bogons.cymru.com, v4.fullbogons.cymru.com, and v6.fullbogons.cymru.com – Team Cymru bogons list. A bogon is a route that is not assigned to an ISP or other end-user and should never appear in the Internet routing table, and are commonly found as source IPs for DDoS attacks. These zones can also be accessed as TXT queries for more detailed information.
- dnsbl.sorbs.net – Aggregated zone for the Spam & Open Relay Blocking System (SURBL) (see their page for more details and available zones)
- spam.rbl-dns.com – Open relays, hijacked PCs, and spam sources.
- dul.rbl-dns.com – Dynamic, ADSL, Cable, and no PTR networks.
- bl.rbl-dns.com – Combination of spam.rbl-dns.com and dul.rbl-dns.com in a single zone.
Querying these services is rather simple, requiring that you reverse an IP address and append the zone to it before querying your local DNS for the corresponding A record. As an example, we can run a test to query zen.spamhaus.org for 127.0.0.2 by querying “2.0.0.127.zen.spamhaus.org” and decoding the result based on the guidance on the Spamhaus ZEN page.
$ nslookup 2.0.0.127.zen.spamhaus.org Non-authoritative answer: Name: 2.0.0.127.zen.spamhaus.org Address: 127.0.0.2 Address: 127.0.0.4 Address: 127.0.0.10
These response codes indicate that our test IP is listed on the SBL, XBL, and PBL lists. Each service will be different, however, and you will have to decode each services’ responses according to their specifications.
Domain Research using RPZs
Much like the IP services, there are DNS-based services that can be queried for information on domains. Some of these are referred to as RHSBLs, or Right-Hand Side blocklists, which refers to the portion of an email address where the domain resides. A few of these services are mentioned below, but you can find others with a little bit of searching:
- dbl.spamhaus.org – Spamhaus Domain Blocklist (DBL) – Domains owned by spammers and used for spam or other malicious purposes.
- <dqs access key>.zrd.dq.spamhaus.net – Spamhaus Zero Reputation Domains (ZRD). This lists newly registered domains for 24 hours.
- dnsbl.sorbs.net – Spam & Open Relay Blocking System (see their page for more details and available zones)
Here, we query Spamhaus DBL for a random domain pulled from ThreatFox:
$ nslookup otopmarketshop.com.dbl.spamhaus.org Non-authoritative answer: Name: otopmarketshop.com.dbl.spamhaus.org Address: 127.0.1.105
If we reference the table in the DBL FAQ, we see that the response of 127.0.1.105 corresponds with “abused legit malware,” which tells us that the domain is valid but has been hijacked for hosting malware.
Domain Research using DNS Providers
There are several DNS providers that have integrated malware filtering into their services, protecting ordinary users and businesses alike from threats automatically. The public IPs for these services can be queried with domain names to see if the hostname resolves or gets redirected. The most popular services are:
- OpenDNS by Cisco (208.67.222.222, 208.67.220.220)
- CloudFlare Public DNS for Families (1.1.1.2, 1.0.0.2)
- Norton ConnectSafe DNS (199.85.126.10)
Below is an example of querying these services for a known malware hosting domain. Note that OpenDNS provided a valid IP address for the host and would have provided no protection for users accessing this domain. Norton DNS “blocked” the request by providing a redirected IP address, however.
$ nslookup > server 208.67.222.222 > data-host-coin-8.com Non-authoritative answer: Name: data-host-coin-8.com Address: 31.28.27.130 > server 1.1.1.2 > data-host-coin-8.com Non-authoritative answer: Name: data-host-coin-8.com Address: 0.0.0.0 > server 199.85.126.10 > data-host-coin-8.com Non-authoritative answer: Name: data-host-coin-8.com Address: 156.154.175.215
Most software with DNS resolution functionality doesn’t let you specify a DNS server, however, and you’re forced to use the IP configured at the OS level or from DHCP. Our DNS lookup add-on for Splunk works around that limitation by allowing you to create a new lookup for each external service you want to query.
Other Indicator Research
DNS-based services are out there for other purposes, as well. You can query file hashes and other types of indicators using the following services:
- cymru.com – Team Cymru Malware Hash Registry (MHR). Supports queries for MD5, SHA1, and SHA256 file hashes, including A or TXT record types.
- Spamhaus Hash Blocklist (HBL) – This service is part of the Spamhaus Data Query Service and requires a key to access it. Personal keys are available at no cost, but there are also commercial use options.
- <dqs access key>.hbl.dq.spamhaus.net – Spamhaus HBL file zone
- <dqs access key>.hbl.dq.spamhaus.net – Spamhaus HBL crypto wallet zone
- <dqs access key>.hbl.dq.spamhaus.net – Spamhaus HBL email address zone
Now Do It with Splunk
Splunk ships with a default scripted lookup (defined as dnslookup within the search app) to perform DNS lookups. It works great for querying basic A records using your standard DNS server, but it falls short for anything outside of that. To get serious, we’re going to use our own Add-On for DNS Lookup app for Splunk, which allows us to configure external DNS servers and query for additional record types.
Let’s run a basic example of querying a source IP address to see if it’s a TOR exit node. See the below example for what this would look like (note that we publish our custom macros on GitHub).
We received an output of 127.0.0.100 for our query, which we created from the reversed IP address and the appended DNS zone. When we reference the provider’s site, it tells us that 127.0.0.100 indicates a match. The TXT record provided the verbose data, which gives us the node name, ports, and flags.
From there, it’s a simple process to query a DNS domain using an RPZ. We just add the domain to the zone we want to query and run the same search. In this example, we run this against two zones at once and find that only one of them matches.
To take this a step further, we can create a configuration to reference CloudFlare service for malware domain checking. To do this, we will edit TA-dnslookup/local/transforms.conf.
[dnslookup_cf_a] external_cmd = dns_lookup.py -server 1.1.1.2 -type a fields_list = hostname ip dns_error
Next, we restart Splunk on our search head and run a new search. We deliberately show both results so it’s easy to see if there is a difference between them. Our output shows that there is clearly a modification in the result from CloudFlare, and we can assume it’s malicious.
From here, there are many possibilities on where to take this functionality and how to leverage it within your SOC. We encourage you to experiment with DNS-based services and create alerts and dashboards to gather more context regarding threat indicators from your favorite services. Let us know how you make out in the comments.
Where to Find It
We’ve published the Add-On for DNS Lookup on Splunkbase for free to all Splunk users, and look forward to your feedback. The project is open source and can be found on Github, including documentation. If there’s something else you’d like to see, don’t hesitate to reach out. Happy hunting!
0 Comments