Editor’s Note: This article is a guest post, which is unpaid and non-sponsored content written by an independent contributor. The views and opinions expressed here do not necessarily represent the views of the Petri IT Knowledgebase.
Last month, a number of technology companies came forward with information about a series of successful attacks against their corporate networks. Twitter first blogged about the attack and the associated loss of 250,000 user records, but it did not provide much background, even though there were references to a US-CERT advisory to turn off Java on workstations. In the following weeks, Facebook, Apple, and Microsoft all followed with blog posts of their own informing us that attackers had penetrated their networks by attacking developer workstations through an exploit for a Java 0-day vulnerability.
Facebook’s blog post was the most detailed and interesting because it revealed how they detected the attack: “…we flagged a suspicious domain in our corporate DNS logs and tracked it back to an employee laptop.” After the Aurora attack in 2009 where DNS analysis also played an important role, this is another indication that DNS log analysis is a worthwhile effort for any security team interested in detecting malicious activity.
The logfiles of your DNS resolver contain a wealth of information on the Internet activity of your users and their machines and can be filtered for signs of attacks and malware. In general, you would be baselining the logfiles for normal usage, and then be looking for normal anomalies. Here are some ideas to get you started, including what you can find out from DNS logs.
Identify and graph normal usage patterns for your network. Track frequency of DNS requests for your leading top-level domains (TLDs) and your most active workstations and use that data as a baseline. For example, if deviations are detected, a new TLD rises to the top in usage or a new workstation appears in the list. Simply review the logs to see if the new domains are legitimate.
There are a number of organizations on the Internet (www.malwaredomains.com, ZeuS Tracker are two) that compile malicious domain information and make it available through RSS feeds and other mechanisms. Download and collect these files and use them to filter your DNS logfiles. A match with any of the domains listed as malicious should trigger an in-depth investigation on the workstation that originates the query with your advanced anti-malware toolset. By the way, Lenny Zeltser has an extensive collection of blocklists on his site if you need more datasources.
Ever since the Conficker worm started the trend in 2009, malware often uses a Domain Generation Algorithm (DGA) to contact its command and control center through DNS. The idea is to generate a flood of different random domain names in many different TLDs (top-level domains, i.e. .com, .net, .io, etc) per day. This makes it next to impossible for malware-fighting companies to blacklist the domain names because of the sheer numbers and costs associated with the domains and the additional overhead of having to work with many different registrars. This is a similar strategy that malware authors are using to overwhelm signature based AV systems: to generate so many different malicious files that the local database and delivery networks cannot keep up with the number of updates. The malware author has the advantage here, as he/she knows the algorithm used to generate it by DGA and only needs to register one of the domains to be able to control the malware. If you know the average number of lookup failures for your network, then any significant deviation could be the product of a malware DGA and should be investigated.
In a similar way to DGAs, malware frequently uses dynamic DNS services for its command and control channels. In the average enterprise, network usage of dynamic DNS domains should be absent or at least be fairly low. A baseline analysis can identify the few dynamic DNS domains in legitimate use and those can be whitelisted in your analysis. Again, any significant anomaly from normal numbers in dynamic DNS usage could be an indication of malware and should be investigated.
Above all, your accumulated knowledge of what is normal in your network is crucial. Computers are great at filtering log data, but often it takes just one look from a human to decide whether a domain name makes sense and is legitimate, or whether the name is the product of an artificial algorithm and is therefore most likely used for malicious purposes.
So if you are interested in this approach, I advise you to start small, implement a subset of the analysis techniques suggested, and generate results and graphs that will provide some initial feedback. Once you have some success stories, you can work your way into more comprehensive processing and analysis. Whatever you do, feel free to reach out to me via my blog at Qualys. I would appreciate hearing from you to get your feedback on these suggestions.
By the way, if you have difficulty getting to your DNS logfiles, a DNS sniffer can help. I have used the free “dnstop” to capture DNS traffic and log the significant results to a file that can then be analyzed similar to a normal logfile.