Continuing With More DNSDB Export Examples
The last blog article discussedhow one can lookup information in DNSDB’s dnstable formated files to dump datafor export or perform lookups similar to theDNSDB API query service. This article continuesthat 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 expandingfrom one set of identifiers used by criminals to other resources utilized byother campaigns. To this end, some folks have built knowledge bases containingaddresses, nameservers, and domains related to known threats and malware, andsome 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 eachper-minute file (specified by
-r
) and importing JSON-formatted data intotheir 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-minutednstable 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 beencompromised is when an unknown name points into the network’s IP address range.Network and DNS and security administrators normally work together to bring upnew infrastructure, so having a host from another domain point into thenetwork is a surprise. Perhaps a desktop was compromised or a visiting laptopexisted 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 DNSpointers from outside the network.
Let’s say we’re scanning a network regularly against PassiveDNS. It doesn’tmatter which one, so we’ll leave their name out in this example. This networkhas 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 newdomain 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 thedomain names owned by the organization
($orgdomains)
, we’ll see somethingstick 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 managedsecurity service provider (MSSP) responsible for multiple networks,having an up-to-the-minute view of DNS pointing into managednetworks would reduce the impact of compromised hosts because they’d beidentified faster.
The Zeus Zombie That Just Won’t Go Away
A favorite example showing DNSDB effectiveness was illustratingresources used by the
lindabstewart.com
Zeus botnet which was just takendown over the summer. A single domain name pointed to many IP addresses, andmany seemingly random domain names pointed to the same addresses in a similarmanner, and nameservers affiliated to the names served other names hostedin the same manner. While the domains were suspended, the IPaddresses live on.
If one takes some addresses from the old domain (in a filenamed “ip”) and looks up how they’re being used now, onewill 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 anotherhost name, PassiveDNS data can illuminate it. It might make sense to addthe IPs to a DNS Response Policy Zone or a firewalllist because the IPs are going to continue to be used for badness until the badguys 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 evadehostname-based or URL-based reputation systems though the host names appear tobe 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 pseudorandomdomains (
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 anothernetwork?
Summary
I’ve provided a few examples of what can be done with access to DNSDB Exportin Real Time. Researchers who know what they’re looking for or looking forchanges to DNS infrastructure will now be able to find it more quickly thanbefore, and more easily than listening to the live SIE stream.
Eric Ziegast is a Senior Distributed Systems Engineer for Farsight Security,Inc.
Heading
