A Closer Look at DGA Traffic

Our last post explored a technique used by malware authors to subvert Command and Control server discovery. CryptoLocker was one such malware known to employ a Domain Generation Algorithm in order to communicate with its C² servers. In this post we will dive deeper in to what network traffic generated by this particular malware looks like. These characteristics are useful when it comes to identifying whether a particular malware is employing a DGA and determining the actual addresses of C² servers.

In previous posts, I have utilized open source technologies to provide an environment for dynamic analysis of malware. While this provided an excellent alternative to a homemade lab, I was limited in the type of information and artifacts I could obtain. The artifacts produced are typically a network PCAP and a list of modifications made on the machine. Using virtual machines allows a bit more flexibility and additional artifacts such as memory dumps and paging files to be extracted. While this post will not focus on the analysis of these additional artifacts, the choice was made to utilize a VM-based lab to run the malware in favor of the additional information available.

Network Traffic Analysis

An analysis of the traffic using tcpdump shows an accounting of the DNS requests that are made and as would be expected there are many DNS requests from the infected host 192.168.5.71.

A packet capture was run for approximately seven minutes and could have gone longer due to the fact that CryptoLocker servers have been taken down for quite some time. If the servers were still active, the malware would quit attempting to make phone home requests once it found a valid domain. The NX records returned for the non-existent domains are indicators of DGA-based utilization by the infected host.

During the period in which the packet capture is run, 176 NX records are returned. Any system administrator or analyst seeing this many NX requests should be able to determine that the host making the request is likely infected. We should really be concerned with the requests that return valid records, as these will allow us to determine the true C² servers.

A number of valid A records are returned for IP address 212.71.250.4. Some research on the IP address yields the following information.

It should come as no surprise that this IP address is registered to a datacenter as this is a common tactic of malicious parties. Examination of the ensuing HTTP traffic leads us to believe that our IP address has been sinkholed. Sinkholing is a technique that is used to put a stop to active malware campaigns.  This is to be expected considering the C² servers were taken down quite some time ago.

The Sinkholing of this domain essentially allowed researchers and law enforcement to put a stop to the ongoing malware campaign which was used as a means to extort money from individuals and businesses with infected machines. If not for the ability to analyze both the DGA traffic and algorithm, this would not have been possible.

Performing a profile of this traffic using Scapy gives us a breakdown of the type of traffic that has been observed.

The majority of the traffic consisted of port 53/udp (DNS) traffic. This accounted for 417 total packets during this time period, 176 of which resulted in NX records being returned. There were 241 domains which returned valid A records but only 184 requests were made to the malicious IP. The only other valid external IP address that was used for communications is 123.170.185.211, which is owned by Microsoft and used for NTP time server purposes.

A listing of the NX Domains can be found here while the valid domains can be viewed here. Armed with this knowledge, we have a great starting point for creating countermeasures that will be helpful in preventing further damage. It also gives us a template for recognition of this sort of infection on the network.