Greetings! You all really seemed to like my last post on Dynamic DNS, so I've been invited to come back and talk more about it. In part 1 , we discussed the uses of Dynamic DNS, as well as the various providers of the service and how it all works. We then discussed that while Dynamic DNS may not malicious in and of itself - that if DNS requests to the internet are observed in your corporate/enterprise/SMB network, that in most cases -- it's not good.
In the most benign case, it could be users attempting to access resources at home that have no relevance to your network security. In more sinister cases, it could also serve as an indicator of users attempting to bypass security controls – for instance if you see a Dynamic DNS request to toteslegit.dyndns.org, then through NSM observe flows to this domain over ports associated with remote access tools (e.g. 3389 - RDP, 22 - SSH, 8080/3128 - HTTP proxy, etc.), it certainly does not look good. In the worst-case scenario, it could be an indicator of a malware campaign that has managed to slip your defenses.
I alluded to wide varieties of malware that have utilized Dynamic DNS. To put it simply, there are far too many to name. I found a post in the Cisco security blog that does a really good job of breaking it down. There's a menagerie of malware out there that utilizes Dynamic DNS to some extent – For command and control, hosting/retrieving a next stage payload, determining the IP address of the compromised system the malware is running on, etc.
1 This illustration from the Cisco security blog shows the top ten abused Dynamic DNS domains by number of malware samples that utilize those domains to some capacity. This graphic and the data was generated by Cisco.
In addition to the Cisco security blog, there was another post by the OpenDNS security team that also broke down the top abused Dynamic DNS domains from their perspective.
2 This is a compilation of OpenDNS' results. There is some overlap with the Cisco Security Blog's results, but there are some unique results here as well. This graphic and the data was produced by OpenDNS labs.
One of the more recent campaigns (and one of the most infamous) was Microsoft's takedown of the njrat botnet. Njrat used the No-IP Dynamic DNS service for its command and control. Microsoft, through a civil suit, gained authority over a large number of No-IP's domains for a period of time and routed Dynamic DNS traffic to their servers to identify and deactivate the command and control... only in doing so, they wiped out service for millions of free and premium users of the No-IP service as well, who were legitimate users. The illustration below shows the impact of Microsoft seizing the No-IP domains and then failing to keep service available for legitimate users. This campaign demonstrates that while Dynamic DNS can be used for malicious intent, there are many more users who utilize the service for other purposes.
3 Dynamic DNS can be used for malicious purposes, but this illustration proves it isn't as simple as shutting down the domain, that there are a lot of other customers utilizing Dynamic DNS services for other purposes. This graphic and the data was generated by No-IP.
After my guest blog, I was talking to the lovely Kate Brew (@securitybrew) regarding the first article, and she suggested that I take a look at AlienVault's Open Threat Exchange, and see how and where Dynamic DNS fits into identifying threat and actor data being shared over the OTX network.
I'll be honest in stating that I had not heard of AlienVault's OTX until very recently, when another group of malware analysts and hunters that I greatly respect, began utilizing OTX for sharing their research. This, combined with the suggestion from Kate convinced me to create an account.
I decided that I would do a little bit of number-crunching myself. Before we begin here, I don't claim to be a data scientist, or very good with the maths, but most the work I did here wasn't terribly complex, so I'm pretty sure my results are fairly accurate. I created a list of the top malicious Dynamic DNS domains featured by Cisco and OpenDNS' research, plus the domains I wrote snort rules for in the first part of this blog post. Then I searched through AlienVault's OTX pulses and recorded how many times a Dynamic DNS domain has been mentioned in a pulse. This data does not account for a single pulse having multiple Dynamic DNS domains (overlap), but here are my results:
4 Number of times a given Dynamic DNS domain was mentioned in a pulse.
After I did this I decided to download the CSV data for every pulse where the Dynamic DNS domains were included as an Indicator of Compromise (IOC). After de-duplicating the downloaded CSV files, I came across 60 unique IOC documents that Dynamic DNS played some part in - Exploit Kits (Easter, Fiesta, Angler, etc.), multiple Remote Administration Tools (RAT) campaigns (njrat, darkomet, Plugx, PoisonIvy, etc.) several APT campaigns (EQUATION, CARETO, BLACKVINE, etc.), Adware, spammers, etc.
5 This was my dataset that I utilized. Each of these documents mentions at least one Dynamic DNS domain that I was looking for. Each of these CSV files represents a threat and set of indicators.
Across the 60 CSV files, there were over 2075 domains of which 1898 domains were unique (sometimes there was more than one pulse for a given threat/campaign). Out of those unique domain names, there were 297 unique Dynamic DNS subdomains (the count for unique Dynamic DNS domains was the same as the total number of Dynamic DNS domains). Dynamic DNS accounts for 15.6% of all the unique, malicious domains identified. The key takeaway here is that this is a non-trivial amount of the overall unique, malicious domains identified, not to mention the fact that each one of these threats utilized at least one Dynamic DNS host.
6 15.6% of all domains identified in my research were Dynamic DNS domains.
What should you do if you encounter dynamic DNS usage in your enterprise network?
Here are a few suggestions:
- Trace the DNS query back to the source. This may be much easier said than done depending on where you are getting data on dynamic DNS requests – If you are getting logs from your DNS Servers (e.g. Active Directory Domain Controllers, BIND, or other solutions, like infoblox), it’s easy to determine which host made the original DNS query. If you are grabbing DNS queries off the wire, via NSM tools (Snort/Suricata, Bro, PassiveDNS, etc.), recursive DNS may be in use in the network (more than likely the case on large networks) and you’ll lose the original source IP address of the client that requested the DNS resolution. It can be very, very annoying.
- Determine the IP address that the dynamic DNS hostname resolves to. If you have NSM logs, now is the time to start gathering them. Gather Netflow records to determine ports/protocols communicated over, length of the conversation, how much data was transferred, etc. any other Snort/Suricata IDS alerts (and pcaps from the alert, if possible) for related events, Bro logs related to the event, etc. We need to answer the who, what, where, when, why and how of the activity.
- If you were successful in tracing the activity back to an IP address and/or user, simply try to contact them and ask what they were doing. If the user has no idea what dynamic DNS is, there’s a good chance whatever is happening isn’t of their own will and will require remediation or further investigation (possible Incident Response actions, etc.) If the activity originated from a server, it’s time to go in to full-on ‘kill it with fire’ Incident Response mode.
Cool new secret weapons
As a conclusion to this post, I wanted to talk about some cool, secret weapons I've developed recently. Part of my day job as a security practitioner involves taking data from a variety of intelligence sources and converting the data/IOCs into rules that we can use on our network sensors for improved detection of threats. This is normally a manual-intensive, (monotonous in some cases) job, even for rules whose content patterns are well-established. What I used to do was copy a well-written rule from the TALOS ruleset, use it as a template, erase the content matches, message and metadata about the rule, then fill in the blanks with the new data.
This can get mind-numbingly tedious especially when you get reports with IOCs consisting of user-agents and somewhere around 50+ domains per report. With this in mind, I developed a pair of scripts to help relieve this burden. I would like to introduce UserAgent2snort.py and dns2snort.py. The purpose of these tools is to turn IOCs into snort rules in an automated manner. UserAgent2snort, as the name implies, converts HTTP User-Agents into snort rules. In order to do this, you simply provide it with a text file with one user-agent per line (with no space on the line, and no blank lines), a file to output the data to, and what SID between one million and two million to begin numbering at. dns2snort works in a similar manner - provide it with a text file containing a list of domains (one per line, no spaces, no blank lines) and a sid number between one and two million to begin numbering at.
If these tools are well-received I could be convinced to continue writing snort rule generators for other IOCs. I'm currently thinking about creating one to convert URIs/site paths into snort rules as well, depending on how well-received these scripts are.
The tools are hosted here and here on my github account and feature a full readme, sample input files and sample output files to show users what the script is expecting, and what output it should produce. I hope they prove to be as useful to you as they've been to me! Happy hunting!
About the Author
My name is Tony Robinson. I am a senior security analyst for a large energy corporation. I can be easily reached on twitter @da_667. Please note that this social media account is my personal account, and does NOT reflect the views of my employer. I have a blog that is updated somewhat regularly with all sorts of juicy infosec goodness and opinions, and a wiki that may be updated sometime in the future as well.