Over the last several months, there has been a lot of interest about Domain Name System (DNS) logging and what can be done with DNS logs. I discussed parts of this topic in my last blog, Finding the Culprit, and will continue to expand on some of those ideas. Many people ask if ActiveGuard® supports DNS logging. While it is not supported at this moment in time, there is a larger discussion to have around the topic.

This larger discussion starts with the number of logs produced by DNS servers. Let’s say an organization of 15,000 employees decides to log all the requests and responses for DNS. This organization would produce approximately 100 logs per second, or 8.6M logs a day. On average, these logs are 750bytes in size, so we will need 6GB per day uncompressed to store these logs. This is not too bad of a number, but you have to remember how your log collection capability is licensed and priced. Keep in mind that this would be one source of logs feeding into your log management platform, and other devices such as firewalls will have much higher volumes.

The second point to consider is what will be done with the logs. If we look at this from a purely detection standpoint, there are a couple of things that could be done with the logs. The first is comparing the domain and IP it resolves to against a blacklist. These blacklists are commonly built from intelligence sources that call out the Indicators of Compromise (IOC). The second is to look at specific attributes of the request and response for anomalies. This could be DNS flags that are set, the byte size of the request, or the combination of options being used. Note that logging DNS is not required to detect protocol anomalies. This can be done using a network based Intrusion Detection/Prevention System (IDS/IPS). As discussed in the Finding the Culprit blog, placement of the IDS/IPS becomes crucial. 

There are some other more advanced detection techniques that can be performed as well, but they can be time intensive and are generally not standard capabilities in log management or Security Incident and Event Management (SIEM) capabilities. This includes reviewing how long the domain has been registered and alert if it is a newly registered domain. Another is looking for domains generated via domain generated algorithms (DGA). The third technique is looking at query frequency for the same domain. If a host is requesting the same domain on or at specific intervals, it may be infected and attempting to beacon out. The last advanced detection is looking for domains that are using fast flux.

Now that we have looked at what these logs can be used for from a detection standpoint, let’s look at what else they can be used for. One major benefit of logging DNS is for incident response purposes. Having these logs allows a team to review what hosts have made specific requests and domains they are trying to resolve. This can help identity additional hosts that may be compromised. It can also help track down the initial infection that caused an incident by identifying the domain that hosted an exploit or acted as a Command and Control (C2) node.

To get some of these detection capabilities that are outlined above in a prevention mode, one option is to subscribe to a DNS service. There are vendors out there that you can point your DNS to and they will resolve suspicious or know bad domains to either localhost (127.0.0.1) or an IP address inside your network. If resolved to an IP address inside your network, you can then setup a DNS sinkhole to find machines performing suspicious DNS request.

So if you want to proceed forward with DNS logging, how do you set it up? The details are outlined in my first blog post, Finding the Culprit. One update to this is if you are using DNS analytic logging in Server 2012 and newer, at this point in time I know of no way to export the logs to an external collection point. Even Windows itself locks the file so that the Event Viewer cannot read the DNS analytical logs when it is enabled. So while Microsoft has made a great improvement to DNS logging, they have no way to get those logs to an external platform while logging is enabled.

References:

http://technical.nttsecurity.com/post/102dwi5/finding-the-culprit-uncovering-the-source-of-malicious-dns-queries

https://technet.microsoft.com/en-us/library/dn800669.aspx

https://blogs.technet.microsoft.com/teamdhcp/2015/11/23/network-forensics-with-windows-dns-analytical-logging/