Using DNS for “Local” Threat Intelligence

In a session I attended at the RSA Conference in San Francisco, one of the panelists was asked a question in the Q&A section about detecting malware that stays entirely in memory, i.e. Avoiding detection by never writing itself to disk. The panelist’s answer was insightful; he stated that malware still needs to communicate with its command & control network, as well as to potentially exfiltrate any data. He suggested among other methods that organisations monitor their DNS traffic, and create a daily dashboard of the top ten domain lookups that have never been looked up before.

While the question was pretty specific, the response had much wider applicability, and resonated with me, because I believe that along with threat intelligence from global sources, organisations need to spend a lot more time and resources on local threat intelligence. Every organisation is different, and what is “business as usual” for one may be “completely out of the ordinary” for another; if we can find the patterns of behavior that are anomalous to the local organisation, we can start to respond appropriately. This not only increases the ability to find threats, it also reduces false positives.

Many protocols can be (and already are) analyzed in this way. However, analyzing DNS for anomalies is a great place to start, because DNS is so fundamental to every network, and underlies almost every other application (including the non-legit ones). Additionally, DNS contains a lot of relationship information between domain names and IPs that can be mined for data.

There are many ways that such analysis can be done, for example to create the dashboard mentioned above, one way would be to enable per-query logging on your DNS server, collect the logs and feed them into an analytics platform such as a SIEM. However, this kind of offline analysis is time consuming, takes a lot of resources, and while it is great to know what happened yesterday, it may be too late if you do spot something that indicates a threat.

However, solutions are now available*, which enable this kind of analysis on your DNS traffic to be done in real time rather than offline, by comparing knowledge of what is happening now against what has happened in the past, and taking action on anomalies that are discovered. The kind of behaviors can be tracked range from simple (e.g. “number of requests”, or “response volume”), to more complex (such as “cardinality (uniqueness) of requests”, or “domain readability”). Additionally, the aggregated behavior analysis can be logged, and that can be fed into SIEM applications, thus allowing such tools to more easily visualize anomalies and behaviors of interest, as well as greatly reducing the volume of data logged. Performing the analysis in real time also enables action to be taken against threats, such as redirecting requests to walled garden servers, or blocking the DNS request.

What kind of threats can be detected using this kind of analysis? Well a good example is the kind of data breach recently highlighted by Brian Krebs (, where data was exfiltrated using DNS tunneling. Another example, going back to the original question above, would be detecting malware that starts looking up completely new domains that have never been seen before by that organisation (particularly useful would be tying that information to the age of the domain; newly or recently registered domains are much more likely to be harboring threats). A more insidious threat that could be detected using this methodology might be a malicious insider or APT that starts looking up internal DNS hostnames that are not usually requested, as part of the discovery phase of an attack.

Either way, and however you do the analysis, I highly recommend starting to think about using the data from your DNS traffic to complement your local threat intelligence. To quote from the Verizon 2014 Data Information Breach Report, “Monitor your DNS connection, among the single best sources of data within your organisation. Compare this to your threat intelligence, and mine this data often.”

*  For example, Cloudmark Security Platform for DNS:

Leave a Reply

Your email address will not be published. Required fields are marked

Learn More About Cloudmark
Our Products
News and Events
Site Map  •  Privacy Policy  •  ©2002–2017 Cloudmark, Inc.