I spend a lot of my time using Carbon Black to look for post-exploit activities. The attackers are far better at finding vulnerabilities and creating exploits than I’ll ever be. The good news is that I know exactly what my adversaries want to do after their exploit is successful. They want to take my passwords, pivot to as many systems on my network as possible, persist so they don’t have to break in again, and steal my data.
Focusing my threat hunting on post-exploit activities is a far more controllable problem than focusing on the exploits preceding them.
A few weeks ago, a penetration tester and an analyst from one of our MSSP partners introduced me to a technique for exfiltration via DNS queries. The method doesn’t use any tools that might not be found on a Linux, Mac or Windows host, and one researcher has published a guide on how to execute the exfiltration from a UNIX host. If you’d like to try the technique yourself I like the following one liner in bash.
Replace <file> with the file name you’d like to exfiltrate and <your server IP> with the IP address of a server you control. Alternatively, you could register a domain name assigned to a server you control and drop the server specification from your dig command. Either way, make sure you log all queries on your DNS server and you’ll be able to recover the file using this method.
On Windows, exploiting this technique takes a little more work because there isn’t a simple hex dump command built into the operating system. Fortunately, there is PowerShell.
I based this command on code discussed on Dr. Sebastian Grottel’s blog. Not being a PowerShell user, I can’t even read most of the code, but it is an effective xxd alternative on Windows. The command simply renders a file, notepad.exe in my case, as lines of hexadecimal text. After that, you’re quick for loop away from sending that data out via nslookup.
After seeing this method demonstrated (and trying it myself) I immediately began thinking about how to detect it with Carbon Black. While this exfiltration lives completely “off the land” using valid system utilities, it leaves a lot of evidence behind.
Here is Carbon Black’s view of a file being taken from one of my Linux virtual machines:
Figure 1 Data Exfiltration via dig
There are certainly a lot of dig commands coming from that one shell, and look at that command line! The stolen data is clearly visible and I hope no human actually uses a hostname like that for legitimate purposes.
Thinking about creating a watchlist, there are a few characteristics that pop out at me:
- There are a lot of child processes.
- This particular exfiltration bypasses my normal DNS infrastructure.
- The hostname looked up in the dig does not look like the natural language a human being would ever use.
Based on observation one, I could try looking for processes with lots of children, but UNIX processes often have lots of children; it’s just how UNIX works.
Based on my second observation, a quick win is to use the following search criteria:
Replace <your DNS server> with your DNS servers’ IP address. Feel free to add as many –ipaddr directives to the query as necessary to eliminate all traffic to your legitimate DNS appliances or servers.
Not that your servers cannot be used to steal data via malicious queries, but as a starting point, identify any activity that tries to bypass your normal DNS infrastructure. Unless a host is a laptop away from the office this traffic likely represents a misconfiguration that should be corrected and may include malicious activity.
The results of this query are also likely to be small compared to the amount of queries typically handled by your DNS infrastructure. These results should be small enough that you can read and react to the information, especially if you clean up any configuration issues. Look for invocations of dig or nslookup and take a look at the command line strings. DNS query exfiltration stands out when compared to a normal request.
Unfortunately, this search will still have a lot of false positives and probably won’t be worth converting to an actionable watchlist. Worse still, an attacker is probably not going to directly query their DNS server but instead will register a domain name and abuse your normal DNS infrastructure to steal your files. The really unique thing about these requests is their odd hostnames, but Carbon Black’s GUI doesn’t have an “odd hostname” criteria.
Over the summer I read an entry in the “Internet Storm Center’s Handler’s Diary,” by Mark Baggett, detailing a method to detect algorithmically created DNS names used by malware. Baggett uses character-frequency analysis to identify odd hostnames and thoughtfully published his analysis code, called freq, to GitHub as a Python module.
Combining Baggett’s freq tool with Carbon Black’s API yields a small script that can find DNS traffic generated with hostnames created by a command line hex dump tool. My cb-dns-exfil.py tool, searches through Carbon Black for DNS connections made by command line tools that have hostnames likely created by software.
To use my script with Carbon Black you will need the Carbon Black API and Mark Baggett’s freq module. I also suggest you read Mr. Baggett’s post and learn a little bit about his freq tool before you begin. I’ve included a frequency table based on English words that works with my script, but you may want to try one of Baggett’s, or create your own. You will also need to edit the script to adjust some of its settings for your own environment.
Running the tool will comb through your Carbon Black data looking for DNS connections that have command line values where the query contains a hostname that doesn’t appear to be a natural language word. The script will print the name of the host where the query originated and the query itself for you to review. Below are a few lines of output from my test system:
The methods shown in this blog are not the only means of stealing data via DNS queries, but I hope I’ve given you some ideas on how to start hunting this exfiltration method. Monitoring for hosts, particularly those used by end users, making a large number of DNS queries, or a high volume of queries in a short period, may also be a good idea.
Looking for any command line invocation that includes an algorithmically generated hostname could also yield results.
Note: dig and nslookup aren’t the only tools that can generate DNS requests. (A simple one-packet ping or any tool that can resolve hostnames is sufficient to leak data via DNS.)
Comprehensively defending against theft via DNS queries requires integrating multiple sources of data. If we apply Mark Baggett’s freq tool against our DNS logs, packet captures and endpoint data, we can then leverage Carbon Black’s API to quickly, perhaps automatically, respond to an incident. We can also combine a commercial DNS security product like Infoblox’s DNS Firewall with Carbon Black’s API to automatically block and respond to DNS exfiltration.