Introduction
There are many, many ways to exfiltrate data from a network, but one common way to do it is using DNS Exfiltration.
With these specific techniques the attackers use the already open port for dns traffic as the door for uploading and downloading data between the attacked host and his own external server.
Obviously with the normal daemon for DNS resolution that’s not possible, but with the right software and the right configuration it is possible to use any DNS server and set it up within any infrastructure to exfiltrate data without the right permissions needed.
But how is possible?
There are many packages already built which are ready to be used for this purpose and the most common are: Dnscat2, Iodine and Powercat+Dnscat2.
Just a quick tip, don’t imagine an attacker using a specific version built only for you. Attackers are lazy and they need to be sure their attack is efficient, so most of the time you will end up fighting with one of these three DNS exfiltration tools. They'll either be renamed or exactly the same as you can find on GitHub.
Remember to also check the second level domain to avoid any confusion with legitimate software using dns tunneling.
So, let’s take a look into these three tools, both work for the same purpose and same TCP/UDP port but with some difference in how to send the data outside the network:
Dnscat2 (https://github.com/iagox86/dnscat2😞 it connects to a server component to try to resolve TXT queries and all data going up and down, to and from, the external server in an encrypted way or not, depending on your choice. This tool is widely used, also because it is ported into multiple programming languages, like Ruby, Perl, PowerShell, etc. This way it can be easier to implement and it'll essentially work on any network.
Iodine (https://code.kryo.se/iodine/😞 same basic functionality as previous one, make tunnel through DNS, but with little difference like password for accessing the tunnel, and uses the NULL type that allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data; there’s also the android version, so all the work is almost done for example to implement it also on IoT device running Android.
Powercat (https://github.com/besimorhino/powercat😞 that tool alone don’t work as a dnstunnel, but if the server part is dnscat2, you can have a interactive Powershell over legitimate dns traffic, and you can increase your capability by adding other Powershell attack framework like Nishang, Powershell Empire, etc..
The purpose of these article is not “how to exfiltrate data from a network”, but let’s take a look how our products can help you to identify and track any usage of these technique in your network, and for that I’ve choose the common approach used every day by me and my colleagues of Incident Response Services.
For that I’ve choosen RSA NetWitness Network. Let’s take a look at the essential steps.
Preparation
In your NetWitness Network click on configure, select as Resource Type Bundle, click Search, choose Hunting Pack and click on Deploy to deploy the hunting pack as showed in Figure 1 to the appropriate component of your infrastructure.
Now choose Lua Parser as Resource Type, click Search and choose nwll and DNS_verbose_lua as parser and click on Deploy to deploy the parser as showed in Figure 2.
Now that your NetWitness Packets (network) environment is ready and have all you need to parse and identify in the right way DNS traffic you can start with your analysis.
Now let’s see how to find bad DNS traffic, or better, the traffic who cross DNS port but is not a real DNS traffic.
Dnscat2 traffic
With right package and parser deployed, if there’s traffic generated by Dnscat2 into your network, many indicators rise to your eyes and help you to fast identify it.
As showed in Figure 3, for Service Type = DNS (service = 53) Service Analysis show presence of “dns base36 TXT record” and “hostname consecutive consonants” plus “dns large answer” as Risk Information and “Hostname Aliases” like the hostname showed in Figure 3 are good sign Dnscat2 traffic presence.
Scrolling to the others meta keys as showed in Figure 4 you find DNS Query Type with value “txt record” and DNS response text with values of many chars without apparent sense, now you have sufficient alerts!
So, in my network there are query for txt record, with base36 encoding, large answer, apparently random text response and random chars host alias? To be sure that’s not a normal DNS traffic you can click on one of these events and see what inside as showed in Figure 5……
Now you have clear that you are in front of Dnscat2 traffic and you have to do further analysis on Source Ipaddress who generate this traffic.
A quick query i apply every day to find its presence in the preferred time span, can be: service = 53 && dns.querytype = 'txt record' && analysis.service = 'hostname consecutive consonants' && analysis.service = 'dns base36 txt record'
Iodine traffic
Let’s check some interesting meta who give me the ability to find Iodine traffic.
As showed in Figure 6 there’s Service analysis with “hostname invalid” and “hostname consecutive consonants”, Risk Suspicious with “dns extremely low ttl”, Host aliases with a lot of “strange” hostname, but check if there’s something more…
As showed in Figure 7 there’s also another interesting filed, DNS query type who say “experimental null record”, so job done, all of these meta are related to Iodine activity and the packet showed in Figure 8 confirm the traffic.
Now you have clear that you are in front of Iodine traffic and you have to do further analysis on Source Ipaddress who generate this traffic.
A quick query i apply every day to find its presence in the preferred time span, can be: service = 53 && dns.querytype = 'experimental null record'
Powercat + Dnscat2
Looking into Powercat + Dnscat2 is different from previous one, let’s check why.
As showed in Figure 9 Session analysis say “single sided udp” , Service Analysis say “hostname consecutive consonants”, dns base 36 txt records”, “dns single request response” and Hostname aliases have a lot of hostname with strange names.
Looking on more meta as shown in Figure 10, there’s DNS query type as “txt record” and DNS Response text with a lot of strange text starting with same char.
Look similar to Dnscat2 traffic but not exactly the same there’s a specific difference between standard dnscat2 traffic and be the “single side udp” and “dns single side request response”.
As showed in Figure 11 there’s only one request and one response, and that’s the main difference from standard dnscat2 and Powercat with Dnscat2.
Now you have clear that you are in front of Powercat with Dnscat2 traffic and you have to do further analysis on Source Ipaddress who generate this traffic.
A quick query i apply every day to find its presence in the preferred time span, can be: service = 53 && analysis.service = 'hostname consecutive consonants' && analysis.service = 'dns base36 txt record' && analysis.service = 'dns single request response'
Addon
Most of the time, when you look into DNS traffic, maybe you encounter something like a client who work not only with UDP but also with TCP protocol.
If the information about the source is right, with these hunting methodology you can archive also some goal about network misconfiguration.
That’s because DNS infrastructure need to be managed and there are a lot of guide on "How to secure your DNS infrastructure", so in a normal situation a client try dns resolution through one internal server, most of the time a domain controller, who talk with a DNS forwarder allowed to go outside of the network for resolution ( if both have nothing into cache).
So if you see a client go to ask resolution from client network to internet , also with TCP protocol, is better if you check more your DNS infrastructure, because one backdoor on client machine using port 53, probably have direct access to internet and you can exfiltrate everything without usage of any dnstunnel, but only using the port allowed.
A quick query i apply every day to find its presence in the preferred time span, can be: direction = 'outbound' && service = 53 && ip.proto = 6 and if your source ipaddress are filled with a lot of ip coming from client network, you have some possible misconfiguration into the network and/or some possible hole.
Finally
There are many ways to hunt and dig into a system, but with the right product and the right methodology you can archive success very faster and this article want be a quick help on doing that because every day we do that with our products!
Hope this helps.
Thank you.
Max
3 Comments
