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.
