Today, serious warnings regarding the increasing number of DNS tunnelling methods are on the rise. Attackers have used such techniques to steal data from millions of accounts. The existing literature has thoroughly demonstrated the extent of the damage which DNS tunnelling can achieve on any given DNS server. However, through SONs - Petri net-based formalisms which portray the behaviour of complex evolving systems, such threats can be alleviated. As a concept, SONs are originally grounded in Occurrence Nets (ONs) and already yielded results in terms of successful cybercrime analysis. For instance, adding of alternates to SONs initially used in [10] was extended to in [15] in order to model and analyse system activities such as cybercrime or accidents, which may show contradictory or uncertain evidence in terms of actual activity. The current paper proposes the use of SON features with the purpose of detecting DNS tunnelling, in the event of an actual attack.
In the last decades, internet usage and spread has grown dramatically,
expanding to include everything and anything, from small, online businesses, to large
company websites. As a consequence, what was initially “the Web” became “Web
2.0”, considering the number of applications which has been developed, based on
the internet. It is the Domain Name System or DNS, which allows applications
to use names instead of numbers (IP addresses), which are considerably more
difficult to deal with. There are several works [
DNS Tunnelling DNS tunnelling is a covert communication channel, which
allows encapsulating the traffic of other protocols (E.g.: HTTP, Telnet, FTP, SSH,
etc.) within DNS packets. This results in concealing the real protocol by making
the traffic look like ordinary DNS traffic. DNS tunnelling is very suitable to be
used for malicious activities such as data exfiltration as well as command and
control call-backs from within restricted internal networks. Different from other
tunnelling methods such as SSH Tunnelling, a distinctive property of DNS
Tunnelling is that, it uses the legitimate DNS servers of the internal network to hop
its packet through, to reach the final destination, which is the attacker-controlled
server DNS Tunnelling encapsulates the data in DNS queries and responses. In
this way, the outer protocol remains as DNS; however, the encapsulated data
payload belongs to another protocol. [
The SONs [
Communication in SONs is of two types: asynchronous and synchronous [
A DNS or Domain Name System assigns domain names and then maps each of
them in accordance with the existing name servers, which host each respective
domain [
Name servers The maintenance of Domain Name Systems is ensured through
distributed database systems, which use client - server models. In this cases,
database nodes consist of name servers. At the same time, for each existing
domain, one or more given DNS servers provide data concerning the respective
domain and the servers of domains which are subsequent to that respective
domain. At the top of this hierarchy, we find root name servers, which typically
receive queries when a TLD must be solved [
Location transparency Location transparency helps to identify existing
network resources, through names, rather than through location [
The review of the existing literature concerning DNS tunnelling led us to conclude that there are two main types of analyses when it comes to this phenomenon: traffic analysis and payload analysis. The focus of our research pertains to the former. 3.1
DNS traffic volume per IP address Traffic analysis detects attacks by
monitoring traffic generated by specific IP addresses (Pietraszek, 2004). The idea is
simple: each tunnelled data request takes up to 512 bytes, a complete
communication will imply sending many requests (Van Horenbeeck, 2006). As such, a
server will continuously send the request, provided the client polls the server [
Number of Hostnames per Domain Guy (2009) suggests the number of
hostnames per domain may indicate the possibility of DNS tunnelling. In such
an event, each request has a unique hostname, meaning there are far more
hostnames as compared to a legitimate domain name. This method can be tailored
to determine an optimal threshold, since various tunnelling methods use various
numbers of hostnames [
Domain history Domain history can help detect DNS tunnelling, as it raises suspicions about DNS traffic. It is used to detect tunnelling by determining when A or NS records were added, since a given domain may have recently been acquired for DNS tunnelling purposes, meaning its NS was recently added (Zrdnja, 2007). This method is used to detect domains involved in malicious activities.
Visualisation Visualisation can also be used to detect DNS tunnelling (Guy,
2009). It involves interactive, analyst driven work [
Data collection constitutes the initial stage of our work. The first step consists of discovering how DNS packets work, how they behave and what their structure is. This step actually consists of two stages which have been conducted in parallel: first, the extensive studying of literature pertaining to the subject and second, capturing real data from a local DNS server. Initially, we captured normal DNS packets. Afterwards, we modelled the normal packet in our model SON. Table 2 illustrates the DNS packet and Figure 4 shows the result. This type of data can be modelled in SONs; however, the “Info” field has various information which must actually be split into different fields. The reason behind this split is to distinguish whether the data packet is either query or response. Additionally, this split serves to distinguish the domain names, but also to determine the packet’s id (0x81fe), since it is this ID which is our indicator, namely the one which links each packet (query) with its response. For instance, row 26 is the query and it is linked with row 29, which is the response for the ID packet in question (0x81fe).
We developed a python script [
Moreover, during the experiments, we collected attack packets, the result of DNS tunnelling attempts. This was, in fact, the second challenge which we discovered and treated. Table 4 represents one such attack packet. As noticeable, if we attempt to model this packet, it will look the same as the normal packet, described above. Due to this, the point of the research is to discover an idea or algorithm which allows the clear distinguishing between normal packets and attack packets. The idea is one must examine each particular domain and its sub-domains, with the purpose of discovering whether or not a specific packet is an attack packet or not.
As such, the python script was updated to split the fields with which we are dealing with, in this case. The main idea for the updated script version is that it loops on each domain field and links it by a unique ID. It is called GroupID. As a result, afterwards, we can identify each chunk of the domain and its sub-domains by that GroupID, as Table 5 illustrates.
Table 5 illustrates the link between the “Google” domain and its subdomains. For instance, we assume “google.com” and “maps.google.com” have the same group id, namely “001”. However, subdomains (paaac5ay) and (paaydani) have been grouped to ”.us.to” via group id, which is actually “002”. So, the idea is to initially identify the domain, i.e. “google” and loop to find any particular sub-domain of “google” and link it with a unique group id. 4.2
In order to simulate a real scenario of DNS server behaviour, the collected data
consisted of two main parts. The first part included the data collected during
the attack experiment. The second part includes normal data, collected from the
university. For this data to make sense, and in order to simulate a real scenario
example, we created python script [
5.1
The main idea of our algorithm to detect DNS tunnelling is to model DNS data i.e., each particular transaction and the way it will communicate with the local DNS server. We assume that each packet is a unique ON. And the local DNS server is one ON. Each packet (ON) communicates with the local DNS server by channel place (thick circle) via events (Send query and receive query), as shown in figure 4 . The client (ONc) sends a query to local DNS server (ONserver), and then DNS server responds to the client as shown in Figure 4. This is the normal packet. When we were to model the attack packet, we found it is the same as the normal one in terms of communication and behaviour. The reason is that we examined each packet as a separate one. However, to detect an attack we need to examine each domain and its sub-domains in order to examine wither we see normal or abnormal packets. For instance, if google.com, map.google.com and developers.google.com are involved, then we need to deal with all google domains and its sub-domains, and model them as one of chunk of domain packets. So, we group each domain and its sub-domains with unique ID as in prepossessing section above. The result is seen in Figure 5, where we can distinguish between normal and abnormal packets (we displayed the attack ON very small to fit the width of the text; however, the ON transaction is actually bigger).
Fig. 5: Normal and Abnormal ONs 5.2
The main idea behind the algorithm is first to detect any ON input, whether it is a normal input or an ON representing a DNS attack. Before going more in depth, it should be mentioned that ONs refer to DNS packets. Furthermore, we assume the local DNS local server to be another ON. It does not matter whether inputs are normal or representing a DNS attack. We examine each ON input and count its events which communicate with the DNS Server ON. If the number of those ON events is less than threshold value, we flag it as a normal ON. Otherwise, we flag it as an abnormal ON. Then, we check whether or not we had abnormal ONs; if so, then we know a DNS attack has occurred. Finally, we should mention that the aforementioned threshold was identified via logistic regression, a widely used statistics model. The idea behind this binomial model resides in properly estimating the parameters of the logistics model. From a mathematical standpoint, the model relies on variables with two possible values, for instance “win” or “lose” or “pass” or “fail”. As such, we applied logistic recognition to available data in order to estimate the threshold, and estimate how many events within a particular GroupID could be suspicious.
The calculated threshold It is at the core of the logistic regression model. From a mathematical standpoint, logistic regression performs multiple linear regression functions of the required feature, such as the number of events. These functions are based on the dependent, dichotomous variable, i.e. “attack” or “no attack”. The aforementioned functions produce a threshold by using the logit equation. Finally, this threshold can be used in our algorithm. The mathematical aim of linear regression functions is to build an equation with the following coefficients: (a) and (c), as follows: y = ax + c, where (y) represents the probability of an attack and (x) is the number of events. Afterwards, the values for both the number of events and the dependent variable, namely “attack” or “not attack”, will be inserted; this will allow us to perform regression analysis, meaning we will be able to calculate the values of (a) and (c), which in turn will increase the likelihood of (y) conforming to ground truth values. Once these values are known, they can be used to calculate the threshold. 18 19 20 21 22 23 24 25 29 30 end
end Algorithm 1: Detection DNS Tunnelling algorithm using SON (Part1) for (Event current_event in current_on’s events) do if (current_event is connected to dns_server_on) then
connected_events_count = connected_events_count +1; end end if (connected_events_count >= attack_max_events) then set_of_abnormal_ons[set_of_abnormal_ons_index] = current_on; set_of_abnormal_ons_index = set_of_abnormal_ons_index + 1; else end set_of_normal_ons[set_of_normal_ons_index] = current_on;
set_of_normal_ons_index = set_of_normal_ons_index + 1;
Algorithm 1: Detection DNS Tunnelling algorithm using SON (Part2)
We considered the following proportions of attacking packets (as percentage of the total packets):
0%, 1%, 5%, 10%, 20%, 40%, 60%, 80%, 90%, 95%, 99% and 100%.
In addition, we used the sensitivity and specificity methods [
First, True positive (TP) result: attack transactions were correctly
identified as attacks.Then, False positive (FP) result: normal transactions were
incorrectly identified attacks.And, True negative result (TN) : normal transactions
were identified as normal transactions.Finally, False negative (FN) result: attack
transactions were incorrectly identified as normal transactions. In terms of the
data mix (of normal and attack packets), we created a Python script [
However, in (2) in Table 6, when the data set had 1% attack and 99% normal packets, we got a 0% True Positive, which means there were no attacked packets detected as attack packets, although we had 1% attack data. This is because the number of packets in this data set was less than the threshold. Regarding False Negatives, we also got 0% because there were no attack packets detected as normal packets. Likewise, in (3) in Table 6, the same situation applied. However, in (4) in Table 6, the algorithm detected 7.1% from a total of 10% of the attack data; however, it failed to detect 2.9% of the attack packets. After we checked the data sets manually, we found that most of these packets were only request queries to the DNS server, to which the DNS server did not respond, so our algorithm skipped them. However, from this 2.9%, the algorithm did not attacked them, although they have query and response packets. In future research, we will further investigate this issue in order to discover why this happened. Another interesting point is that, in (4) in Table 6, there is a False Positive, which means the algorithm detected 9.4% of the normal packets as attack packets; after investigating this, we found that Google had sent many requests to the DNS server as unusual requests, and these request events were above our threshold. When we rerun the experiment, we did not face this issue. Moreover, as evident in (7) in Table 6, no normal packets were detected as attack packets (False Positives). Finally, in (15) in Table 6, the False Positives and True Negatives were “N/A”; this was because, in these data sets, there were no normal packets at all. The paper proposes a novel solution to DNS tunnelling detection based on SONs. An detection algorithm has been designed and implemented. Also, data preprocessing and a set of experiments have been discussed. Further work will focus on improving the current algorithm, aiming at allowing it to work automatically in terms of reading with packets in real-time scenarios. In addition, we will model and develop algorithms dealing with more than one DNS server at a time, including all user packets. In addition, we will use other DNS tunnelling tools, instead of “iodine”, in order to compare various attack behaviours and check how the algorithm deals with these types of attacks.
The authors would like to thank the reviewers for their comments on the paper.