Coronavirus (COVID-19) Information Read here

← Farsight Blog

Farsight's Real-time DNSDB, Part Two



Continuing With More DNSDB Export Examples

The last blog article discussed how one can lookup information in DNSDB's dnstable formated files to dump data for export or perform lookups similar to the DNSDB API query service. This article continues that discussion and adds more examples.

Importing DNSDB Export Data Into Threat Modeling Systems

One of the primary use cases security researchers have for DNSDB is expanding from one set of identifiers used by criminals to other resources utilized by other campaigns. To this end, some folks have built knowledge bases containing addresses, nameservers, and domains related to known threats and malware, and some even utilize machine learning to help classify these identifiers.

It's easy for users to input up-to-the-minute DNS data by just dumping each per-minute file (specified by -r) and importing JSON-formatted data into their system (specified by -j).

$ dnstable_dump -r dns.20151024.1151.m.mtbl -j
{"rrtype": "NS", "time_last": 1445687286, "time_first": 1445687286,
"count": 0, "bailiwick": "ac.", "rrname": "",
"rdata": ["", ""]}
{"rrtype": "NS", "time_last": 1445687286, "time_first": 1445687286,
"count": 0, "bailiwick": "", "rrname": "",
"rdata": ["", ""]}
{"rrtype": "A", "time_last": 1445687286, "time_first": 1445687286,
"count": 0, "bailiwick": "", "rrname": "",
"rdata": [""]}

Without importing the data into a database, we can use dnstable_dump and dnstable_lookup on the command line to look through sets of per-minute dnstable files to start some investigations.

Watching a Network for DNS Surprises

One clear out-of-band warning sign that a machine on a network has been compromised is when an unknown name points into the network's IP address range. Network and DNS and security administrators normally work together to bring up new infrastructure, so having a host from another domain point into the network is a surprise. Perhaps a desktop was compromised or a visiting laptop existed on the network long enough that the botnet controller added the device into their service. A global view into passive DNS replication makes it easier to see these DNS pointers from outside the network.

Let's say we're scanning a network regularly against PassiveDNS. It doesn't matter which one, so we'll leave their name out in this example. This network has several /16 network blocks.

$ cat /tmp/nets

If one scans for all of the rdata IP address space regularly and finds a new domain pointing into it that has nothing to do with the hosting organization, it's worth investigating.

If we compare any recent PassiveDNS on that network that doesn't belong the domain names owned by the organization ($orgdomains), we'll see something stick out…

$ ls dns.20151024.06??.[Xm].mtbl > dns.fileset
$ export DNSTABLE_SETFILE=dns.fileset
$ for net in $(cat /tmp/nets)
        dnstable_lookup rdata ip $net 2>/dev/null | egrep -v '($orgdomains)'

The results included:

... IN A YY.YY.227.136 IN A YY.YY.227.136

The keyword "newmsgforyou" in a domain seems to be associated with some spambots.

As a network administrator for an organization or as a managed security service provider (MSSP) responsible for multiple networks, having an up-to-the-minute view of DNS pointing into managed networks would reduce the impact of compromised hosts because they'd be identified faster.

The Zeus Zombie That Just Won't Go Away

A favorite example showing DNSDB effectiveness was illustrating resources used by the Zeus botnet which was just taken down over the summer. A single domain name pointed to many IP addresses, and many seemingly random domain names pointed to the same addresses in a similar manner, and nameservers affiliated to the names served other names hosted in the same manner. While the domains were suspended, the IP addresses live on.

If one takes some addresses from the old domain (in a file named "ip") and looks up how they're being used now, one will see numerous websites that don't look like they'd be good places to visit.

Here's a sample limited to two domains…

$ ls dns.20151024.06??.[Xm].mtbl > dns.fileset
$ export DNSTABLE_SETFILE=dns.fileset
$ (for ip in $(cat ip)
    do dnstable_lookup rdata ip $ip 2>/dev/null| egrep 'uok|leonli' done) | sort -k 4 IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A IN A

Any time the same actor uses the same IP infrastructure to add another host name, PassiveDNS data can illuminate it. It might make sense to add the IPs to a DNS Response Policy Zone or a firewall list because the IPs are going to continue to be used for badness until the bad guys are caught or the IPs are taken away.

There's a Reason a "DROP" Network Continues to be Listed

If one needs to verify that IP addresses on the SpamHaus DROP list are still pushing out garbage, "Yes, they are." Here's some DNS results from one of the listed /16 networks in the last few minutes….

$ ls dns.20151116.14??.[Xm].mtbl > dns.fileset
$ export DNSTABLE_SETFILE=dns.fileset
$ dnstable_lookup rdata ip | grep -v '^ns[12]\.' | sort IN A IN A IN A IN A

The pseudo-random nature of the host names appears to be an attempt to evade hostname-based or URL-based reputation systems though the host names appear to be lexically similar to each other.

$ dnstable_dump -r dns.20151116.1400.X.mtbl | fgrep kjm. | sort IN A IN A IN A IN A
$ ls dns.20151116.14??.[Xm].mtbl > dns.fileset
$ export DNSTABLE_SETFILE=dns.fileset
$ dnstable_lookup rdata ip | grep -v '^ns[12]\.' IN A IN A IN A IN A

Two entries in DROP point users to somewhat similar pseudorandom domains ( ; SBL262062 and ; SBL214384). Will it be only a matter of time before the users start using another network?


I've provided a few examples of what can be done with access to DNSDB Export in Real Time. Researchers who know what they're looking for or looking for changes to DNS infrastructure will now be able to find it more quickly than before, and more easily than listening to the live SIE stream.

Eric Ziegast is a Senior Distributed Systems Engineer for Farsight Security, Inc.