DNS data exfiltration

22nd February 2017


There are times when you need to get data from A to B but something is blocking your path. The reasons for this can range from security policies to commercial decisions to poorly configured systems. For example, you can imagine a network which is locked down for security reasons but an actor on that network wishes to exfiltrate data. In some of these environments DNS will still work (most firewalls allow port 53 traffic through unhindered)…

If we could tunnel data through DNS then maybe we can achieve our goal. In fact there are many openly available projects make this process relatively simple. At it’s heart you have a client which generates DNS queries something like:

[encoded data].[some_domain]

“some_domain” is a genuine registration which has nameservers that will be able to process that encoded data. Data can flow back to the client contained within the response.

One of the better known projects is called “Iodine” (named after element 53); and we can learn a lot about it from its man page. One interesting feature is its use of the qtype NULL (qtype 10) which is unusual enough that it should stand out in our data.

Thinking about what this traffic will look like in our authoritative data it makes sense that any queries will be for domains that exist and where we return a delegation (as opposed to queries for, say, .uk which get an actual answer). So our filter should be qtype=NULL(10), rcode=NOERROR and AA bit clear in the response.

Overview: Missing data

Some of these dots contain packets that just happen to match our filter, but do not look like exfiltration at all (they are requests for “www.[somedomain].uk“). Some however do look like iodine in action. Of course in our data we only see the first query before the answer is cached for a period of time (which might explain the periodicity seen in our traffic).

In order to see the whole conversation then you could either look at the traffic to your local recursive server or watch all DNS traffic leaving your network. If you do this then what you will see is something like:

Top 100

In many cases the whole domain approaches 255 characters; which is the upper limit for legal names. Other QTYPES are used, but the choice has some consequences on the available bandwidth for download (server to client traffic is held in the response and different QTYPES allow different responses).

More generically then we can look for long QNAMES with seemingly random text, possibly mixed case as this would increase the payload.

Should it be felt that this traffic should be blocked then care will need to be taken as legitimate applications can generate queries with long random-looking domain names. For example, consider the following requests:

c-0.19-a7000081.c0481.15ea.79e.3ea3.210.0.nrnmzcq4rrlakdkatkv5gjvcwb.avts.mcafee.com

a3000081.0.16a8.b29.3ea5.210.0.junwez349tm7s6l2iqktpz6pgv.avts.mcafee.com

Which, while bearing the hallmarks of data transfer, are in this case an antivirus product submitting a suspect file hash for identification. This mechanism has been seen to be used by point-of-sale (POS) malware as a channel to get stolen credit card details out of the local network. It is also used in some VPN solutions to allow for data transfer after a mobile account has used up all of its data quota.

In conclusion the use of DNS as a data transfer channel is happening, for a multitude of reasons. It leaves a very clear signal in your traffic, but that only helps if you are looking for it.