Keywords

1 Introduction

Data exfiltration is one of the most common objectives of sophisticated and often multi-stage cyber threats, such as Advanced Persistent Threats (APTs) [1]. During data exfiltration, APT malware or insider attackers often transfer valuable data (such as trade secrets and customer information) gathered in the compromised system over the network to the threat actors. Data exfiltration poses serious security threats, for example, McAfee reports that insider thefts accounted for 50% of data loss in Asia-Pacific, 40% in the UK and 41% in North America [2]. In response, network security mechanisms (such as firewalls) have introduced various filtering policies based on protocols or communication ports to prevent direct (overt) exfiltration of data.

Unfortunately, attackers have turned to covert communication channels to exfiltrate data by bypassing firewall restrictions. For example, HTTP and DNS are basic protocols that provide the functionality necessary for Internet browsing, so most firewalls allow HTTP and DNS communication between internal hosts and external servers. However, HTTP offers a possibility of data exfiltration through methods such as request parameters, custom headers, and cookies. While the most common protocol exploited by data exfiltration is HTTP [3], by embedding the data into DNS queries, an attacker can also covertly exfiltrate information across network boundaries. According to a recent DNS security survey [4], 46% of respondents experienced DNS exfiltration. There has been significant research in terms of both covert channel attacks [5,6,7,8,9,10,11,12,13] and covert channel detection [14,15,16,17,18,19,20]. However, the arms race among attackers and defenders with respect to covert exfiltration of data has never stopped.

In this paper, we propose a novel data exfiltration attack that exploits both HTTP requests and DNS queries. Our attack scheme relies on trusted web services as an intermediary for data exfiltration from a bot running on a node behind the firewall to a blocked external endpoint.

More specifically, the common firewall policy adopted by network administers is to block certain domains, and a more radical one is allowing users access to only a white list of domains that are considered safe. We observe that many web services take a domain name or an URL as input and then visit that domain/URL somehow. For example, the web service Google Search by Image [21] can take an URL as input and then retrieve the image that the URL points to. To retrieve the target image, the web service has to send a DNS query to the name server of the domain name within the URL.

Our goal is to abuse such web services for the purpose of data exfiltration from behind a firewall to a bot master holding an authoritative name server for a domain. To achieve our purpose, a public web service must satisfy the following requirements:

  1. (1)

    It is not blocked by the firewall. In other words, the web service is trusted by the firewall.

  2. (2)

    It takes a domain name as input and then makes DNS query to the name server of the input domain name. It can also take an URL as input and then makes DNS query to the name server of the domain name within the URL.

Figure 1 demonstrates how we can use a public web service such as DNS Nslookup online [22] as an intermediary for data exfiltration. DNS Nslookup online accepts a domain name as input and then issues a DNS query to the authoritative name server of the input domain name. The input domain name is the place where we embed the data (e.g., in the format data.somesite.com) that we want to send to the bot master who is the authoritative name server of a public domain (e.g., somesite.com) and is blocked by the firewall.

Fig. 1.
figure 1

Data exfiltration with DNS Nslookup online as an intermediary

Full size image

Moreover, if a web service takes an URL as input and makes a HTTP request with the input URL, we can embed the data to be exfiltrated into the domain name within the input URL. Then before the HTTP request is sent out, a DNS query will be first sent to the authoritative name server of the domain name. Figure 2 shows this procedure if we use Google Search by Image as an intermediary for data exfiltration.

Fig. 2.
figure 2

Data exfiltration with Google Search by Image as an intermediary

Full size image

In this way, the bot does not communicate with the blocked domain directly but it can send the data to the bot master. Another benefit of the model is that when the law enforcement takes down the bot master, it is hard to trace back from the bot master to the bot because the bot master just receives DNS queries from a public web service.

In this paper, we make the following contributions:

  1. (1)

    We propose a novel data exfiltration attack that abuses trusted web services as intermediaries to establish DNS covert channels to the destination.

  2. (2)

    We design and implement a prototype of the attack.

  3. (3)

    We experimentally verify the feasibility of our attack by identifying 16 trusted web services and using nine of them to transfer data from a bot behind the firewall in a protected network to a bot master, and the transmission rate is up to 520 bits per second.

  4. (4)

    We explore possible defenses against our attack and build a proof-of-concept detector that should run on the trusted web service.

We organize the rest of paper as follows: Sect. 2 describes the design of our attack. Section 3 proposes the implementation details. Section 4 presents the results of an experimental evaluation, demonstrating the effectiveness of our attack. Section 5 discusses possible defense ideas. Section 6 explores related work. Section 7 concludes the paper.

2 Design

Our attack model deals with five entities. Figure 3 summarizes their relationship. Among them, bot, firewall, public web service and bot master are necessary in our attack model, while HTTP proxy is optional:

  1. (1)

    Bot: it runs in the system of a user behind the firewall of a constrained network. The bot tries to exfiltrate data to its bot master outside. We assume that the bot is somehow installed in the user’s system (e.g., through drop-by downloads, email attachments, or social engineering) despite the presence of the firewall. A malicious insider can also directly run the bot.

  2. (2)

    Firewall: an authority that monitors the traffic between the internal user and the outside network and can block any packet as it wishes. It also blocks the access to certain domains, but it does not record every monitored data session or IP endpoint. It deploys DNS tunnel detection and restricts the web access of internal users so that the users cannot directly access the domain held by the bot master. However, the firewall does not block public web services since blocking them will not only cost too much but also cause users much trouble to use legitimate popular services.

  3. (3)

    Public web service: an online web service used as an intermediary in data exfiltration, which is located outside the constrained environment. We assume that the firewall does not block traffic between the internal user and the web service.

Fig. 3.
figure 3

Illustration of the relationship between the principal entities. Our system enables indirect one-way channel from the bot to the bot master

Full size image

In our attack model, the public web service is a very important entity. It should be able to accept a HTTP request with the data to be exfiltrated and then make a DNS query with a domain name that has the data embedded. For convenience, we want the public web service to have an input field and the input should be a domain name or contain a domain name so that it is easy to embed data in the input.

Formally, the public web service must incorporate two functions: the input parser f and the domain name resolver g. The input parser f accepts an input of URL or domain name and then extracts domain name from the input (if needed), which can be formalized as the following function:

$$ f:{\text{I}} \to {\text{D}} $$

Here I represents the set of input URLs or domain names, and D represents the set of domain names.

To resolve the domain name to IP address, the public web service sends DNS query to the authoritative name server of the domain name, which can be formalized as the following domain name resolver function:

$$ g :{\text{D}} \to {\text{Q}} $$

Here we define D as the set of domain names, and Q as the set of DNS queries.

Then we can treat the public web service as a composition function as follows:

$$ g^\circ f :{\text{I}} \to {\text{Q}} $$

In other words, it accepts an URL or domain name as input and generates DNS queries that can be exploited for the purpose of data exfiltration.

Guided by the above formalization, the first type of real world web services that can be used in our attack are online DNS services such as online DNS nslookup, online DNS dig and so on. These services take a domain name as input and send DNS query with the input domain name to its authoritative name server. Therefore, for them the input parser function f is simply the identify function.

However, online DNS service is just one kind of public web services that our attack can abuse. More generally, any public web service that takes an URL as input and makes a HTTP request for this URL can be a candidate too. Therefore, we can use the web services that fetch the web page pointed by the input URL. This kind of public web services can represent a large class of public web services such as search engine (e.g., Google Search by Image) and online virus scanner (e.g., Dr. Web online [23]).

  1. (4)

    Bot master: it holds the authoritative name server of a public domain that is known by the bot but is blocked by the firewall. We assume that the data exfiltration need only a one-way channel from the bot to the bot master.

  2. (5)

    HTTP proxy: it is an optional entity in our attack model. To make a more stealthy attack, we can use another public web service as a HTTP proxy to visit the public web services. In this way, we add one more layer of indirection to make our attack method stealthier.

3 Implementation

As illustrated in Fig. 3, our data exfiltration method involves the bot master, the public web service, the bot, and optionally the HTTP Proxy. We have built a proof-of-concept prototype for this attack. Below we will discuss various components in more details.

3.1 Bot Master

We bought a public domain name inviserver.com. Then we use the bot master machine in our lab as the authoritative name server for inviserver.com. In more detail, we bound the IP address of the bot master machine to ns1.inviserver.com so that any DNS query for inviserver.com will be forwarded to the bot master.

In order to retrieve data from DNS queries, the bot master leverages the open source DNSCat [24] server. DNSCat is a DNS tunnel tool, which can be used for data transmission between two hosts via DNS queries. The DNSCat server can accept and parse the incoming DNS queries. Only when the domain name of the incoming DNS query matches the format of DNSCat domain name, can the DNSCat server retrieve data from it; otherwise, the DNS query is ignored.

For example, if the domain name in an incoming DNS query is dnscat.30.iouoafrx.1.2f2a20.746370.kgmi.inviserver.com, which matches the DNSCat query format dnscat.<flags>.<session>.<count>.<data field 1>.<data field 2>.<garbage>.<domain>, then the data fields are “2f2a20746370”, which is hexadecimal encoded from the string “/* tcp”. Therefore, the data transmitted by this DNS query is “/* tcp”. In this way, the normal DNS query to inviserver.com will not interfere with the data transmission.

3.2 Bot

We implement the bot by extending a version of DNSCat client. We set 8.8.8.8 (Google public name server) as the name server of the bot machine, and select one public web service to use from Table 1. We use the modified DNSCat client to convert data into a sequence of domain names that match the format of DNSCat domain name. Then for each domain name, we create a python script, taking the domain name as input, to make a HTTP request to the selected public web service with the domain name or an URL containing the domain name. For each public web service, we prepare one unique python script. During the whole process, we do not use any browser, which makes our method stealthier. Below we demonstrate a concrete example.

Table 1. Public web services
Full size table

Suppose we select Google Search by Image as the public web service for our data exfiltration and the piece of data we want to transfer is “/* tcp”. The modified DNSCat client will first convert the data into a domain name dnscat.30.iouoafrx.1.2f2a20.746370.kgmi.inviserver.com. Since Google Search by Image can take an URL as input, our python script (googleimage.py in Fig. 4) first converts the given domain name to an URL (e.g., www.google.com is converted to http://www.google.com), and then makes a HTTP Post request with the URL to Google Search by Image. Then a command: python googleimage.py dnscat.30.iouoafrx.1.2f2a20.746370.kgmi.inviserver.com is executed by the modified DNSCat client.

Fig. 4.
figure 4

The python script googleimage.py for the public web service Google Search by Image

Full size image

The public web service Google Search by Image will first accept the URL: http://dnscat.30.iouoafrx.1.2f2a20.746370.kgmi.inviserver.com and then try to fetch the image pointed by the input URL (although this URL does not point to an image in our experiment). Thus, before fetching the image, a DNS query with the domain name dnscat.30.iouoafrx.1.2f2a20.746370.kgmi.inviserver.com will be sent and finally be forwarded to the authoritative name server of the domain inviserver.com, which is actually the bot master.

3.3 HTTP Proxy

We also build a prototype that leverages public HTTP proxies. Specifically, Google uses some undocumented proxies to provide content to the users. When we access any page via one of these Google proxies, the content of that page is downloaded to Google servers and then served to us. We find two Google proxies that can be used as HTTP proxies in our method:

  1. (1)

    Google Modules. The gmodules.com domain is part of the Google personalized homepage service and is mainly used to host gadgets that are available for the Google homepage. If we want to visit example.com with Google Modules as a proxy, the URL should be http://www.gmodules.com/ig/proxy?url=http://example.com

  2. (2)

    Google Mobilizer. Although Google has discontinued the main mobilizer service on google.com, we can still access it through any country-specific Google domain like google.i.e. or google.co.in. If we want to visit example.com with Google Mobilizer as a proxy, the URL would be http://www.google.ie/gwt/x?u=http://example.com

For example, if we use Google Search by Image as the public web service with Google Modules as a proxy, we can simply replace the URL in Fig. 4, “http://www.google.com/searchbyimage”, with “http://www.gmodules.com/ig/proxy?url=http://www.google.com/searchbyimage”.

4 Experiment and Evaluation

In this section, we present the experiment results of our evaluation. The bot master is installed on a Linux machine with a 2.93 GHz, 2-core Intel Xeon CPU and 4 GB of RAM, running an Ubuntu 12.04 system. The bot is running a Linux machine with the same hardware and operating system as the bot master machine. Figure 5 demonstrates the system architecture.

Fig. 5.
figure 5

The system architecture

Full size image

As we discussed in Sect. 2, we investigate 16 public web services that our method can exploit. Table 1 lists these public web services. We first test the data transmission rate without HTTP proxy for the first nine public web service in Table 1 by exfiltrating a 34,183-byte file (arbitrarily chosen by us) multiple times. During the experiment, none of the public web services was able to detect our data transmission. Table 2 presents the results for the data transmission rates.

Table 2. Data transmission rates of public web services
Full size table

Then we perform experiments with HTTP proxy. We use the public web service DNS Nslookup online with the Google Modules and Google Mobilizer as HTTP proxy (as we mentioned in Sect. 3.3) to exfiltrate a 34,183-byte file multiple times.

As a result, if using Google Modules as a proxy, the file exfiltration takes 641 s on average and the transmission rate is 427 bit/second. If using Google Mobilizer as a proxy, the file exfiltration takes 688 s on average and the transmission rate is 397 bit/second. The data transmission is not detected by either the proxies (Google Modules and Google Mobilizer) or the public web service DNS Nslookup online. Comparing with the transmission rate (465 bit/second) without using a proxy, the transmission rate with a proxy is relatively lower but still acceptable.

5 Defense

In the section, we discuss the defense ideas against our attack and a proof-of-concept defense.

5.1 Defense Idea

In our attack, the network traffic that involves the data exfiltration can be classified into two categories: (1) HTTP requests from the bot to the public web service; (2) DNS queries for the input domain name or the domain name within the input URL, which is sent by the public web service. Below we first discuss the defense by monitoring HTTP requests and then the defense by monitoring DNS queries.

A defense can be placed at the frontend of a public web service by monitoring the incoming HTTP requests. From this point of view, we can consider it as a HTTP tunnel detection problem. Since our attack embeds the data in the input domain name or the domain name within the input URL, a possible solution is to analyze each HTTP request and extract the domain name from it. If the domain name is abnormal (e.g., with a weird format or too long length), a temporary blocking can be applied to the IP address where the HTTP request is sent from. On the other hand, to achieve a high transmission rate, our prototype sends HTTP requests to a public web service without any pause. As a result, the public web service will receive many HTTP requests from the same IP address within a very short period of time. A simple idea is to limit the number of HTTP requests from the same IP address within a certain period of time. In this way, although we cannot completely stop the data exfiltration, its throughput decreases.

Unfortunately, a bot can overcome the above rate-limiting approach by utilizing multiple public web services simultaneously to exfiltrate data to the bot master. The idea is to split the data to be exfiltrated into multiple streams and use one public service for each stream, and then let the bot master assemble information from the multiple streams to recover the original data. In this way, although the throughput of each individual stream is low due to rate limiting by the public web service, the overall throughput can still be good enough for the attacker. Therefore, this kind of attack would be difficult to counter.

If we place the defense on the local DNS server of the public web service, we can monitor the DNS queries sent by the public web service. Then this problem is able to be reduced to a classic DNS tunnel detection problem. For example, we can adopt information measurement based DNS tunnel detection [18] or bigram based DNS tunnel detection [19]. The local DNS server can apply these two techniques for detection purpose. To stop the data exfiltration, the public web service also needs to cooperate with the local DNS server so that when the local DNS server detects a suspicious DNS query, the public web service should figure out which incoming HTTP request leads to the sending of this DNS query. Then the source IP address of the HTTP request likely belongs to the bot and should be blocked.

5.2 Proof-of-Concept Defense

In this subsection, we discuss our proof-of-concept defense. Since we do not control any public web service, we set up a web server with DNS nslookup functionality to simulate a real web service. We apply the defense on the local DNS server of this web server. Our defense relies on the information measurement approach inspired by Paxson et al. [18], which is based on assessments of information-theoretic entropy. The intuition is that DNS tunnel traffic carries higher amount of information than normal DNS traffic. Therefore, we can detect DNS tunnel traffic by testing whether its information amount exceeds certain threshold. Specifically, the technique works in two phases. In the training phase, we measure the information amount of known DNS tunnel traffic and legitimate DNS traffic in order to learn the threshold that can tell the difference between them. Then in the detection phase, if the information amount of any DNS traffic is beyond the threshold, our defense will generate a warning of possible DNS tunnel traffic. Below we will discuss the details.

Information Measurement

Attackers can exploit DNS query name, time and record-type to carry covert information. For example, an attacker can abuse query time: a time interval between successive queries of 1 s conveys a 0 bit and a time interval of 10 s conveys a 1 bit. We build a monitor on the local DNS server and measure the amount of information conveyed by incoming DNS queries. The queries are grouped by (lookup name suffix, client IP)-pair. For each group, the information amount is measured in query name, time and record-type sequences separately: each sequence is compressed with different compressors (zip, bzip2 and ppmd [38]) and the smallest size of the compressors’ output is the estimate of the amount of information conveyed by this sequence. The sum of the estimated sizes of the three sequences is the estimate of the amount of information conveyed by this group of DNS queries.

Threshold

For real time detection purpose, we set the sliding window of size 100 and step 10 for our monitor, which means that the first information measurement will cover the 1st to 100th DNS queries, the second one will cover the 11th to 110th DNS queries, the third one will cover the 21th to 120th DNS queries, and so on.

To measure the information amount of the DNS tunnel traffic, we perform a similar experiment as we did in Sect. 4. The difference is that we use our web server as the public web service. We transmit files of different sizes. During each transmission, our monitor groups the received DNS queries and measures them. The DNS queries in the (inviserver.com, IP of web server) group are in charge of the file transmission and some of the measurement result is shown in Table 3.

Table 3. Information measurement result of data exfiltration by DNSCat
Full size table

We then use normal browsing as training workloads. During training, we collect the information amount of 10,000 query groups. Figure 6 shows the distribution of the information amount. We can see that the amount of information in about 8,200 groups (or 82% of the 10,000 query groups) is less than 100 bytes, and the information amount of 99% groups is less than 300 bytes. The maximum information amount is 415 bytes among all groups, while the average information amount of the DNS tunnel traffic groups in Table 3 is nearly 9,000 bytes. Based on the measurement results and considering some room for fault tolerance, we choose 500 bytes per group as the threshold to differentiate legitimate DNS traffic from DNS tunnel traffic; namely, if the information amount of a group is greater than 500 bytes, a warning will be generated that it is possibly used by a DNS tunnel.

Fig. 6.
figure 6

Distribution of information amount in the 10,000 groups used in training

Full size image

Experiment

Under the configuration (sliding window of size 100 and step 10, and the threshold 500 bytes per group), we perform real time information measurement for the file transmissions (mixed with legitimate DNS traffic) mentioned before. As a result, our monitor is able to classify all the DNS queries in (inviserver.com, IP of web server) group as suspicious ones without any false negative. In other word, with this selected threshold, our monitor can achieve 100% detection rate and be free from false alarms.

Furthermore, our monitor can report the suspicious DNS queries to the public web server and let its administrator figure out which HTTP request leads to such DNS queries. Then the administrator can take actions (e.g., he can ban the IP of the source of the HTTP request).

6 Related Work

Covert Channel

HTTP is one of the most frequently used protocols for Internet browsing. Moreover, attackers can abuse HTTP in different ways for covert communication. The traditional way of exploiting HTTP is by sending HTTP requests to web server, with covert data encoded as URL parameters [5]. Moreover, covert data can be encoded into header field values, order of header fields, use of lower or uppercase, presence or non-presence of optional headers, use of multiple white spaces and nonstandard header fields [12, 39, 40].

Closely related to our paper, Fifield et al. [9] create a HTTP tunnel that uses a web-based online scanning service (OSS) as the intermediary for a censored user to communicate with a blocked end point. When compared with our method, their method has more limitations than ours. First, the OSS plays a similar role as the public web service in our method—both work as an intermediary. However, OSS has to take an URL as input while public web service can take either an URL or a domain name as input. Second, OSS can only communicate with the target via HTTP requests, which means that the public web services that just make DNS queries (e.g., DNS Nslookup online) cannot be exploited in their method. As we discussed in Sect. 1, before sending a HTTP request, a DNS query for the domain of the web server must be made first. So the OSSs (e.g., Dr. Web Online scanner) in their method can also be used in our method. As a result, our method is more flexible in terms of the choice of the intermediary. Since we add one more layer of indirection (HTTP and DNS system), our method is more stealthy.

Domain Name Service (DNS) maps domain names to IP addresses. Because DNS is one of the basic protocols on the Internet, most firewalls allow DNS traffic, which opens the door for abusing DNS for covert channels. PSUDP [7] is a tool that creates a network-wide messaging system by piggybacking on legitimate network DNS traffic. Born [6] presents a covert DNS channel using JavaScript with modern browsers. Heyoka [11] is a proof of concept exfiltration tool, which uses spoofed DNS requests to create a bidirectional tunnel. Xu et al. [13] explore the feasibility of only using DNS queries to stealthily and effectively maintain large botnets. They hide tunneling DNS query activities by piggybacking tunneling queries with legitimate DNS queries and distributing the DNS queries temporally.

Covert Channel Detection

There are many techniques that detect covert channels such as HTTP tunnels and DNS tunnels by analyzing the captured flows of the network traffic (e.g., HTTP packets, DNS packets). As we discussed in Sect. 5, either HTTP tunnel detection techniques or DNS tunnel detection techniques can be potentially used as the defense against our attack.

Xu et al. [13] propose a statistical method that can be employed in deep packet inspection to detect DNS tunneling packets. In their method, they use Jensen-Shannon divergence to compare the probability distributions of normal DNS traffic and tunneling traffic, and further detect tunneling packets.

Borders and Prakash [14] detect HTTP tunnels based the analysis of the HTTP request regularity, inter-request delay, bandwidth usage, and transaction size. BRO [41] and Snort [42] identify tunnel traffic based on detailed analysis of each packet payload. Bernaille et al. [43] use a statistical approach for traffic identification by clustering based on the analysis of packet size. Crotti et al. [44] achieve the same goal by finding inconsistencies in inter-arrival time, order and size of the packets on the IP layer.

Born and Gustafson [15] detect DNS tunnels by analyzing the unigram, bigram, and trigram character frequencies of domains in DNS queries and responses. Qi et al. [19] develop an approach that scores the query name in a DNS packet based on bigram and distinguishes DNS tunnel domain names from normal domain names and DNS tunnel ones by comparing the bigram score of a domain name with a threshold.

Zhang et al. [20] present a method to differentiate DNS covert channel from normal DNS traffic based 48 features on DNS packets (e.g., the length of packets). Dietrich et al. [16] propose a technique that distinguishes between DNS-based C&C and regular DNS communication, which is based on rdata features and aggregated behavioral communication features.

Karasaridis et al. [17] build a system that calculates the Relative Entropy (the significance of the change in the behavior of the DNS traffic) hourly between baseline DNS packet-size distribution and observed one. If the Relative Entropy exceeds a certain threshold, the system will raise an alarm for possible DNS tunnel traffic.

Information Measurement

Some researchers work on the measurement of the amount of information conveyed by network traffic.

Borders and Prakash [14] present an approach that can quantify information leaks via HTTP. They measure the maximum volume of leaked data by filtering repeated and constrained message fields from HTTP requests. Since our method exploits HTTP requests for the communication between the user behind a firewall and the public web service, their approach can be applied on the firewall or on the front end of a public service to measure the information leaked via HTTP requests, which can possibly further detects the existence of our data exfiltration (e.g., by comparing the amount of the leaked information with a threshold).

As we discussed in Sect. 5.2, Paxson et al. [18] propose a measurement procedure that measures information volume conveyed through the DNS queries and can detect surreptitious communication through DNS queries, whose information volume exceeds a configurable bound. Since our method leverages DNS queries from the public web service to the bot master, the local DNS server of the public web service can apply this method for detection purpose.

7 Conclusions

In this paper, we propose to abuse general-purpose public web services that accept a domain name or an URL as input for covert data exfiltration from a bot in a confined network to a blocked bot master. Blocking all these public web services is practically impossible to do and will introduce much more inconvenience to users in the internal network.

After identifying a large class of public web services that can be exploited, we build a proof-of-concept prototype that can exfiltrate data from a bot behind the firewall to a bot master, using these public web services as intermediaries in our data exfiltration. We run experiments to demonstrate the effectiveness of our attack and evaluate the transmission rate for each public web service. Finally, we also develop a proof-of-concept defense against such novel data exfiltration attacks.