Spikes and Query Patterns

A spike in DNS queries can sometimes be an indicator that a certain domain is either hosting malicious content (such as an exploit kit) or serving as a command-and-control (C2) server. However, relying solely on spiking traffic is often not enough. Many benign websites have spikes in traffic that are not related to malware activity but instead a popular blog post or a referral from a big traffic website (reddit, NYTimes, etc). This blog post will be examining the different types of spikes we see across OpenDNS’s worldwide resolvers.
One simple method to filter out benign domains that have a spike in DNS queries over an hour is to look at the historical trend of DNS queries to that domain. This filter looks at the average traffic received by a domain over the course of a specified time window and discards domain which have an average traffic over a certain threshold. This crude filter works well in removing domains who historically have had near constant traffic with few deviations. The class of domains removed by this filter are rarely malicious.
Simple filters can help bubble up websites that are potentially malicious such as

 
*[.]escortlarankaratr[.]net – a compromised domain hosting the nuclear exploit kit. However, challenges still lie. The following domain is a good example of a false positive that can occur.
Lets examine the following query pattern for the domain umuthuzmeleri[.]files[.]wordpress[.]com:

 
Here is an example of a domain experiencing a sharp spike in traffic. However, a manual investigation of the site reveals that it is not hosting any malicious material (at the time of the spike). Ideally, we would like to see if looking at query data we can find some information that would allow us to identify this spike as benign. Once again looking at the historical query history of the domain provides some valuable information. Let us zoom into the data for a week snapshot before the spike:

 
Historically this domain received low traffic but in a consistent pattern that was repeated over a week. This type of traffic pattern is most likely associated with a normal website. Our first filter was a basic filter which removed domains that had an average hourly DNS request count over some threshold. Our second filter will capture the periodic behavior of request traffic and filter out domains that exhibit periodic behavior for some specified time window. We create a composite signal which represents the average behavior of periodic DNS queries to websites with low traffic. A cutoff filter is created which filters out domains which have periodic signals which deviate by small error constant from the original composite signal. A more sophisticated filter could be created but the goal is to create a quick filter which will allow us to rapidly prototype and test out ideas. This filter serves as an easy and quick way to filter out a large class of false positives. Development and analysis of the more complicated filters used will be subject of another blog post.
There is another piece of information that we can use to help augment our decision making. Let us see if any of the clients requesting the domain during the large spike are on any known spam blacklist. Interestingly, the majority of clients participating in the spike were seen on blacklists created by Project HoneyPot. The spike could be a possible attempt by an attacker to perform a mail inject or brute force a password. As a result, we do not classify this domain as malicious but instead monitor for suspicious redirects coming from the website. This could be a sign that the spammers who created the spike were suspicious in compromising the website. Relying on traffic patterns and well established blacklist we can help identify and label different types of spikes that we see.
Future work involves designing a method to cluster the different types of spikes. Clustering provides an analyst an easy way to visualize patterns within spiking domains. It also serves as useful preprocessing step before further classification.