Effectively Detecting Low Throughput and Malicious DNS Exfiltration

In a previous blog post, we described how the DNS protocol, mainly designed for hostname to IP addresses resolution, can be abused for arbitrary data exchange. Based on throughput (i.e., bytes per hour), we distinguish between two classes of data exchange over the DNS protocol.

The first of the two classes, dubbed high throughput DNS tunneling, includes a family of freely available software that allows message forwarding over the DNS protocol. This can be used for web browsing, remote desktop control, and file transfer. The required communication reliability for these tasks over the unreliable UDP protocol, often requires an overhead of control messages. Also, the DNS name limit of 255 bytes per message [13] will often require a large number of messages. Therefore, both the control overhead and the message size limitations often involve a significantly higher throughput of bandwidth (at least 10kb/s) with regard to the normally sparse DNS traffic. A slight and significant change of throughput makes this class relatively easy to detect using volume limitation rules and/or statistical models. 

The second class of low throughput DNS exfiltration malware was created by attackers in order to evade volume limitation rules and statistical models designed to detect DNS tunneling. These malware variants’ evasion techniques involve short and sporadic communication between the malware and its command and control (C&C) server. For example, upon a successful website login on a compromised machine the malware will only exfiltrate the username and password over the DNS protocol. Such techniques make traditional DNS tunneling detection solutions ineffective against these malware variants. 

The goal of this blog post is to explore the behavior of low throughput DNS exfiltration malware and how the capability in Akamai’s Enterprise Threat Protector solution provides effective detection of high throughput tunneling and low throughput exfiltration malware.

The Use of Dedicated Domains

In the previous blog post, research into seven known low throughput exfiltration malware variants were introduced, including Wekby, MULTIGRAIN, and FrameworkPOS. This section explores a unique behavior of these malware variants that allows us to design a solution capable of detecting them without relying solely on the DNS traffic message volume and density.

Malware analysis reports related to these seven known malware variants indicate that all used domains that were registered and operated by the malicious actors for the sole purpose of data exfiltration (see Table 1). The names of these domains were chosen to be either short (e.g., 29a[.]de) to possibly allow longer messages within the 255 bytes message cap, or to resemble popular services. Among these dedicated domains is a23-33-37-54-deploy-akamaitechnologies[.]com, the C&C associated with FrameworkPOS malware that impersonates an Akamai Technologies’ host.


Used Domains


cspg[.]pw, algew[.]me, etc. [1]


dojfgj[.]com [2]

Wekby / pisloader

ns1[.]logitech-usa[.]com [3]


LS4[.]com [4]


29a[.]de [5]


a23-33-37-54-deploy-akamaitechnologies[.]com [6]


ns4[.]msftncsl[.]com [7]


images[.]moviedyear[.]net [8]


ms[.]jifr[.]co[.]cc, ms[.]jifr[.]net, etc. [9]

Table 1 – A list of known DNS exfiltration malware and domains used for their operation. All of these domains were of no use other than the operation of a cyber campaign.

Moreover, based on the communication patterns of the above malware, we expect the queries to these domains to be non-readable and longer on average. The following example queries display this behavior:

  1. FrameworkPOS credit-card exfiltration sample [6]:

  1. DNSMessenger ‘MSG’ message sample [1]:

  1. BernhardPOS credit-card exfiltration sample [5]:

As a midway summary, previously encountered malware were all associated with lengthy queries (at least 50 characters on average), in-readability due to encryption or encoding, and domains that were registered mainly for the data exfiltration operation. Therefore, a security system that is capable of detecting domains with such attributes is arguably a good solution against DNS exfiltration. With this in mind, we’ll now focus on how to detect these behaviors. 

Leveraging Cloud-based Security

The average length of a subdomain is a straightforward computation. The remaining challenge is to learn a length threshold to allow a good distinguishing of DNS exfiltration domains from the rest. This can be done with the use of prior examples of DNS exfiltration queries, legitimate queries and statistics.

The in-readability of subdomains can be inferred using information entropy. Information entropy is a measure which is often associated with the detection of encryption and non-readability [10] [11] [12]. It estimates the uncertainty of an upcoming character based on a history of characters, thus it increases as characters are chosen more randomly compared to English dictionary words. In order to achieve statistically significant results, the history of subdomains per inspected domain should be sufficiently large. 

The last, but arguably most challenging, task is to eliminate domains that are not dedicated for DNS exfiltration. While the former tasks are independent and require no historic or global knowledge, this task potentially requires knowledge about users, hosts, geographical locations, and organizations to better ensure that the detected domains serve no other purpose. Such inspection would include the overall number of users and organizations, initial appearance, and access stability (over time) based on its users, etc. As users’ data varies, it allows more accurate results regarding the legitimacy of inspected domains.

Based on the above, the detection of dedicated domains for DNS exfiltration improves with the volume of traffic and the variety of its users. Compared to endpoint and on-premise solutions, a high volume of traffic and large variety of users is best attained with cloud-based security products such as Akamai’s Enterprise Threat Protector (ETP).

How Does ETP Detect DNS Exfiltration?

The core of ETP’s threat intelligence is a Big Data platform that collects and processes more than two billion DNS logs on hourly basis. For the sake of detecting DNS exfiltration, these logs are grouped and examined according to the queried domain (e.g., all queries to * Such groups will be referred to as domain-specific traffic.

Each time the data is collected, an anomaly detection model is used to classify each domain-specific traffic as either: (1) DNS exfiltration or (2) legitimate traffic. Anomaly detection models are statistical models designed to detect samples that do not conform to normal behavior. To that end, these models are trained only on legitimate traffic and inspect features such that their abnormality will imply abuse of the DNS for data exchange. For example, two of the model’s features are the average length of queries and information entropy over domain-specific queries. A wise choice of features and data granularity helps the anomaly detector achieve optimal results in distinguishing the anomalous samples from the rest of the traffic.

ETP’s DNS exfiltration detection model is evaluated using simulations. After being trained on several days of legitimate DNS traffic, it is tested with future legitimate traffic, as well as generated DNS exfiltration attacks. The attacks contain both high throughput DNS tunneling (e.g., Iodine, Dns2tcp, DNSCat) and low throughput malware (e.g., Wekby and a self-implemented credit-card exfiltration malware). Overall, the model was evaluated using more than 75,000 legitimate samples, as well as nearly 2,000 DNS exfiltration samples. The model was able to achieve high detection rates even on low throughput malware. 

ETP’s DNS exfiltration detection achieves superb results on both DNS tunneling and low throughput DNS exfiltration. Moreover, the research around detecting is still ongoing in order to explore new techniques and improve results.


The detection of low throughput DNS exfiltration is difficult and has been generally ignored by many detection mechanisms. In this blog post, we gave a look into how ETP as a cloud-based security product aims to cope with the problem. The anomaly detection engine implemented within ETP does not rely on the behavior of existing malware, but rather on features that make DNS exfiltration stand out when compared to regular DNS communication. ETP’s detection engine reaches high detection rates with very low false positive rates, thus making it much harder for miscreants to exfiltrate data outside of a restricted network.


[1] –

[2] –

[3] –

[4] –

[5] –

[6] – 

[7] –

[8] –

[9] –

[10] – Gianvecchio, Steven, and Haining Wang. “Detecting covert timing channels: an entropy-based approach.” Proceedings of the 14th ACM conference on Computer and communications security. ACM, 2007.

[11] – Dorfinger, Peter. Real-time detection of encrypted traffic based on entropy estimation. na, 2010.

[12] – Antonakakis, Manos, et al. “From Throw-Away Traffic to Bots: Detecting the Rise of DGA-Based Malware.” USENIX security symposium. Vol. 12. 2012.

[13] –

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Asaf Nadler. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)