This document discusses DNS monitoring and analysis for incident response. It begins by explaining why DNS is important to monitor, as it underpins all network activity and malware frequently uses DNS. It then discusses collecting DNS data at the border, resolver, and endpoint levels. Common collection tools include IDSes, passive DNS loggers, and native resolver logging. The document outlines enriching DNS data with information like WHOIS and blacklists. It provides examples of DNS analysis like detecting fast flux domains, tunneling, DGA, and low prevalence domains. It notes common false positives and discusses response actions like using RPZ (Response Policy Zones) to block or redirect malicious DNS queries.

1. DNS in IR: Collection,
Analysis and Response
Philip Martin

2. Who am I?
• Security Lead at Coinbase (I’m hiring…)
• Recovering software engineer
• Done other security stuff other places, almost entirely blue team
• @SecurityGuyPhil

3. Why care about DNS?
• DNS underpins everything and everything leaves traces *or the
absence of traces* in it’s use of DNS
• DNS is reasonably simple to log (and definitely much simpler than
something like endpoint logs)
• Even so, DNS is rarely logged effectively and even more rarely
analyzed to it’s full potential
• Even more rarely is DNS used effectively for response (internal
sinkholing is awesome!)

4. Why care about DNS?
• 91.3% of malware uses DNS (2016 Cisco Security Report)
• 68% of companies don’t monitor DNS (2016 Cisco Security Report)

5. I’m convinced! I want to log DNS!
…
Umm, how do we do that?

6. First a note about names
• We frequently conflate Passive DNS and DNS Monitoring, but they
actually aren’t the same thing.
• Passive DNS is a specific technique invented by Florian Weimer in
2004 that focuses on capturing between recursive and authoritative
nameservers. The goal of Passive DNS is to rebuild an accurate
picture of the global DNS database. It’s awesome, but we’re not
going to talk about it today.
• DNS Monitoring, on the other hand, is the comprehensive logging of
all DNS activity on a given network. This is what we’re going to talk
about.

7. How do we collect DNS at scale?
• Collect at the border
• Collect at the resolver
• Collect on the endpoint
• Hybrid
• Tools:
• Bro/suricata/ids
• Gamelinuix PassiveDNS
• Native resolver logging
• My thing

8. Where should we collect DNS?
Collect at the border
• Pros
• You see all requests
• Probably have spare
capacity
• Cons
• Might not see the true
client
• Can’t collect internal
requests
• Won’t see cached
responses

9. Where should we collect DNS?
Collect at the resolver
• Pros
• You see the true clients
• You can see internal
requests
• Cons
• You need to worry
about perf impact
• You miss queries direct
to external resolvers

10. Where should we collect DNS?
Collect at the endpoints
• Pros
• You get data on and off
network
• Cons
• You need to worry
about perf impact
• You need to deal with
data transport
• You need to deal with
deployment headaches

11. Where should we collect DNS?
Do it all
• Pros
• You see everything
• Cons
• You need to worry
about perf impact
• You need to worry
about duplicate
collection
• You need to worry
about
deployment/collection

12. Collection Tools – Resolver logging
Resolver Logging Capibility Log format
Bind Question only Text-based, semi-structured
Microsoft DNS 2012+2 Question and Answer Text based, semi-structured
Unbound Question Dnstap1
djbdns / dnscache Question Esoteric strings
1dnstap is a fairlynew protobuf-based logging format, with support in KnoxDNS and Unbound. It has yet to
gather a ton of momentum among other systems, but it’s a good idea.
2Prior to Windows 2012, windows DNS logging had huge performance issues during sustained use.

13. Collection Tools – IDSs
• Most modern IDSs have some kind of DNS logging system
• (Snort is a notable exception)
• IDS, however, are generally a border-only thing in most companies
IDS Logs DNS? Format
Snort No n/a
Surricata Yes Structured text
Bro Yes Structured text

14. Collection Tools – Passive DNS logging
• Log DNS by sniffing network traffic and re-building question/answer
legs.
• 2 standalone options:
• Passivedns – https://github.com/gamelinux/passivedns
• Gopassivedns – https://github.com/Phillipmartin/gopassivedns

15. Infrastructure
• Needs to support multiple clients submitting data
• Needs to support an intermediate enrichment step
• Needs to write to a data store that can handle both interactive search
and batch calculation
For example:

16. Awesome, I have all the DNS data!
…
Umm, what can we do with all this
data?

17. How do we make sense of it all?
• Enrichments (whois, rbls, GEOIP, etc)
• Analysis examples
• Detect fast-flux
• Detect tunneling
• Detect DGA
• Low-prevalence domains

18. Enrichments
• whois
• Very useful for things like domain age and registrar reputation.
• Blacklists
• Great for reputation-based filters and investigations
• Pull for questions and answers
• GeoIP on returned IPs
• Add some pre-processed strings
• extracting domain from the query
• Calculating English word presence
• Query entropy / compressibility

19. Analysis – fast-flux
• Fast-Flux domains rapidly switch IPs for the same domain in an effort
to avoid easy IP-based blocking
• This, however is blindingly obvious when viewing DNS logs based on
the number of IPs that a given domain resolves to and the generally
low TTL of those lookups.
• You can frequently locate these hosts with a ‘unique IPs per domain’
count while excluding some obvious false positives like CDNs

20. Analysis – DNS Exfiltration/Tunneling
• Most DNS exfiltration/tunneling tools use a single domain and a large
number of unique hostnames and responses to create a duplex
channel
• This is where you need either a pre-computed ‘domain’ field or
something like Spark.
• Try sorting by the number of unique hostnames per domain.

21. Analysis - DGA
• DGAs generally result it large numbers of NXDOMAIN responses for a
client
• They may also result in highly entropic domain names
• Try searching for hosts with a large number of NXDOMAIN responses

22. Analysis – Low Prevalence Domains
• Prevalence is the number of unique clients that have looked up a
domain in a given time.
• C2 domains (assuming an attacker is not using an established cloud
service as a transport) should be relatively uncommon in your
environment.
• Users also tend to go to a lot of random domains and DNS prefetch
doesn’t help matters. The usefulness will vary depending on your
users and environment.
• Servers, on the other hand, shouldn’t have the user problem (and if
they do, you have other problems).

23. Analysis – Some other leads
• Which of your hosts have the most TXT lookups?
• Which domains have the most TXT lookups?
• Which of your hosts have the most NXDOMAIN responses?
• Which of your hosts do the most DNS lookups?
• Which domains are the least looked up if you exclude error
responses?
• External IPs in netflow that don’t show up as a DNS answer?

24. Analysis – Common False Positives
• AV engines frequently use DNS for updates.
• Be careful of lookalikes, however:

25. Analysis – Common False Positives
• Some things, notably Tor and Chrome, attempt to detect local DNS
hijacking by issuing requests for randomly generated domains at
startup.
• Some browsers can issue very aggressive pre-fetch queries for partial
domain names that the user never actually visited (e.g. a lookup for
www.cn while the user was typing www.cnn.com).
• CDNs generally cause analysis issues based on their fairly random
subdomains and generally high lookup volume, but fairly easy to filter
out.

27. Ok, I’ve found the APTs. Now what?
• Because DNS is so central to networking, it’s also a great place to
block things.
• Even more interestingly, it’s a great place to redirect things for further
inspection.
• The primary method for doing this kind of blocking is a mechanism
implemented by Bind called Response Policy Zones (RPZ)
• Much has been written about RPZ, sometimes also referring to it as a
“DNS Firewall”.

28. RPZ Explained

29. What is RPZ good for?
• RPZ is obviously useful for blocking domains.
• RPZ can also be used to redirect requests to transparent proxy servers
for enhanced analysis, drop in a click-thru warning page
(downloads.cnet.com perhaps?) or direct users to a remediation
website.
• RPZ is FAST, especially if you’re using zone change notification.

30. RPZ Gotchas
• Unfortunately, RPZ is just another Bind zonefile, with all the
configuration maintenance gotchas that come along with that.
• If you plug standard DNS block lists into RPZ, you’re going to have a
bad time. (after the second time I blocked itunes, I learned that
lesson).
• Always remember to update the zone serial number.

31. goRPZ
• This was going to the coming out of my open source RESTful RPZ
server…
• But it’s still in in legal review, so not so much today 
• Any day now, however, it will be up at
https://www.github.com/Phillipmartin/gorpz

32. Questions?