Farsight's Real-time DNSDB, Part Two

← Blog Home

RSS

By

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": "aaf.ac.",
"rdata": ["dns01.gmoserver.jp.", "dns02.gmoserver.jp."]}
{"rrtype": "NS", "time_last": 1445687286, "time_first": 1445687286,
"count": 0, "bailiwick": "aaf.ac.", "rrname": "aaf.ac.",
"rdata": ["dns01.gmoserver.jp.", "dns02.gmoserver.jp."]}
{"rrtype": "A", "time_last": 1445687286, "time_first": 1445687286,
"count": 0, "bailiwick": "aaf.ac.", "rrname": "90.aaf.ac.",
"rdata": ["210.172.183.49"]}
...

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
XX.XX.0.0/16
YY.YY.0.0/16
ZZ.ZZ1.0.0/16
ZZ.ZZ2.0.0/16
ZZ.ZZ3.0.0/16
ZZ.ZZ4.0.0/16

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)
    do
        dnstable_lookup rdata ip $net 2>/dev/null | egrep -v '($orgdomains)'
    done

The results included:

...
lepidolitem.newmsgforyou5.net. IN A YY.YY.227.136
agentialn.newmsgforyou345.net. 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 lindabstewart.com 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
ns1.leonliklerts.at. IN A 107.15.99.91
ns2.leonliklerts.at. IN A 107.15.99.91
ns3.leonliklerts.at. IN A 107.15.99.91
ns4.leonliklerts.at. IN A 107.15.99.91
uokkwqswimaamcwe.org. IN A 109.254.116.68
uokkwqswimaamcwe.org. IN A 134.249.238.140
uokkwqswimaamcwe.org. IN A 141.101.3.36
uokkwqswimaamcwe.org. IN A 176.104.102.59
uokkwqswimaamcwe.org. IN A 176.104.24.228
uokkwqswimaamcwe.org. IN A 176.106.31.227
ns1.leonliklerts.at. IN A 176.113.149.167
ns2.leonliklerts.at. IN A 176.113.149.167
ns3.leonliklerts.at. IN A 176.113.149.167
ns4.leonliklerts.at. IN A 176.113.149.167
uokkwqswimaamcwe.org. IN A 176.113.149.167
ns1.leonliklerts.at. IN A 176.36.174.59
ns2.leonliklerts.at. IN A 176.36.174.59
ns3.leonliklerts.at. IN A 176.36.174.59
ns4.leonliklerts.at. IN A 176.36.174.59
ns1.leonliklerts.at. IN A 178.150.153.18
ns2.leonliklerts.at. IN A 178.150.153.18
ns3.leonliklerts.at. IN A 178.150.153.18
ns4.leonliklerts.at. IN A 178.150.153.18
uokkwqswimaamcwe.org. IN A 188.230.31.190
uokkwqswimaamcwe.org. IN A 188.231.147.199
uokkwqswimaamcwe.org. IN A 193.107.135.125
uokkwqswimaamcwe.org. IN A 212.22.192.224
uokkwqswimaamcwe.org. IN A 31.128.74.100
uokkwqswimaamcwe.org. IN A 31.129.95.173
uokkwqswimaamcwe.org. IN A 46.119.173.111
ns1.leonliklerts.at. IN A 67.161.171.204
ns2.leonliklerts.at. IN A 67.161.171.204
ns3.leonliklerts.at. IN A 67.161.171.204
ns4.leonliklerts.at. IN A 67.161.171.204
ns1.leonliklerts.at. IN A 73.36.213.39
ns2.leonliklerts.at. IN A 73.36.213.39
ns3.leonliklerts.at. IN A 73.36.213.39
ns4.leonliklerts.at. IN A 73.36.213.39
uokkwqswimaamcwe.org. IN A 73.36.213.39
uokkwqswimaamcwe.org. IN A 77.122.27.116
ns1.leonliklerts.at. IN A 86.100.133.94
ns2.leonliklerts.at. IN A 86.100.133.94
ns3.leonliklerts.at. IN A 86.100.133.94
ns4.leonliklerts.at. IN A 86.100.133.94
uokkwqswimaamcwe.org. IN A 93.185.211.46
ns1.leonliklerts.at. IN A 93.79.146.80
ns2.leonliklerts.at. IN A 93.79.146.80
ns3.leonliklerts.at. IN A 93.79.146.80
ns4.leonliklerts.at. IN A 93.79.146.80
uokkwqswimaamcwe.org. IN A 94.244.141.40
ns1.leonliklerts.at. IN A 94.76.127.113
ns2.leonliklerts.at. IN A 94.76.127.113
ns3.leonliklerts.at. IN A 94.76.127.113
ns4.leonliklerts.at. IN A 94.76.127.113
uokkwqswimaamcwe.org. IN A 94.76.127.113
...

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 42.128.0.0/12 | grep -v '^ns[12]\.' | sort
0edm4kjm.myanmately.pw. IN A 42.141.33.201
0gjn3kjm.ceremoving.space. IN A 42.141.10.48
0gtm4kjm.constaging.us. IN A 42.141.17.81
0kzn4kjm.buries.biz. IN A 42.141.40.104
...
zitn4kjm.feders.biz. IN A 42.141.41.231
zkdo1kjm.ashokai.eu. IN A 42.141.24.174
zmdo0kjm.colonking.eu. IN A 42.141.25.121
zuto3kjm.rosexual.pw. IN A 42.141.36.242

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
0edm4kjm.myanmately.pw. IN A 42.141.33.201
0etn4kjm.lassicat.biz. IN A 116.190.167.85
0itn4kjm.imporatin.xyz. IN A 116.190.22.212
0mjn4kjm.gointersity.be. IN A 116.190.205.162
...
zgjn4kjm.churchanged.eu. IN A 116.190.159.58
zqdn4kjm.onlinebrass.us. IN A 116.190.25.63
zudm2kjm.thetitute.us. IN A 116.190.57.33
zyto3kjm.searbicithe.be. IN A 116.190.63.221
$ ls dns.20151116.14??.[Xm].mtbl > dns.fileset
$ export DNSTABLE_SETFILE=dns.fileset
$ dnstable_lookup rdata ip 116.190.0.0/10 | grep -v '^ns[12]\.'
0adm4kjm.ratake.be. IN A 116.190.62.115
0adn4kjm.recentrol.be. IN A 116.190.212.223
0atn1kjm.numergot.be. IN A 116.190.207.206
0atn4kjm.civilial.eu. IN A 116.190.66.4
...
zyto3kjm.ratevers.be. IN A 116.190.62.104
zyto3kjm.searbicithe.be. IN A 116.190.63.221
zyzn4kjm.ehtat.biz. IN A 116.190.60.234
zyzn4kjm.professionnelas.com. IN A 116.190.62.200

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

Summary

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.

← Blog Home

Protect against cybercriminal activity in real-time.

Request demo

Email: sales@farsightsecurity.com Phone: +1-650-489-7919