SSL encryption being used in malware command and control

Evolution in malware command and control presents a significant challenge to network based intrusion detection. According to an October 2011 report by TrendMicro some targeted attacks are making use of SSL encrypted command and control communications. These techniques are a response to defensive measures taken against standard command and control mechanisms which use specially created domains and DNS. Damballa's work provides an example of such defense. Here are some excepts from the TrendMicro report.

"There are malware samples that use webmail accounts as elements of command and control. When malware connects to well known services such as Gmail or Yahoo! Mail the session is protected by SSL encryption and therefore network monitoring software will be unable to determine if the subsequent traffic is malicious or not. The attackers use such webmail accounts to send commands to compromised hosts, update compromised hosts with additional malware tools or components, and ex-filtrate data from compromised hosts. In addition to webmail services, could-based storage services are being used to host additional malware components. The use of such services provides the attackers with command and control infrastructure that cannot be easily detected as malicious."

"Some threat actors use compromised legitimate sites as command and control servers. This allows the attackers some element of deception because even if the network communication is detected as anomalous, upon further inspection the website will be determined to be legitimate. One threat actor simply embeds commands within HTML comment tags in web pages on compromised, legitimate web sites. The malware simply visits these pages and extracts and decodes the commands. The use of custom base64 alphabets and XOR makes decoding the command and the network traffic increasingly difficult. In addition, attackers are making use of stolen or forged SSL certificates in an attempt to make their network traffic appear to be legitimate."

These techniques make detection of command and control communications very difficult and will defeat many network based IDS. This situation reveals problems at the core of computer security. A small change by the attacker results in a significant expense by defenders to produce new defensive measures. Lets look at the most troubling of these techniques.

SSL encrypted session with Gmail, command and control via Gmail

An example, syschk.ocx (md5:16ba21c1eac48eb20c04ac91ef9c2bd1) is available at the links below.

http://www.nartv.org/2010/10/22/command-and-control-in-the-cloud/

http://contagiodump.blogspot.com/2010/10/oct-08-cve-2010-2883-pdf-nuclear.html

http://pastebin.com/8f51r7Q0

How is an enterprise to detect this? One detection option is to use an SSL interception proxy and then run signatures over the decrypted traffic. But this is terribly cumbersome, running an SSL interception proxy can be a nightmare for a large enterprise. And this suffers from the problems standard IDS has which is that the system only detects known threats. The other is to use anomaly detection to detect anomalous SSL flows, some research on this has been done, see this report. But anomaly detection suffers from high false positives, and I have my doubts about whether this would work with a large enterprise. In addition an attacker could modify their malware so that C&C communications better mimic standard SSL communications.

As the Australian Defense Signals Directorate showed network based IDS is not the best way to prevent targeted attacks. The best approach involves an effective OS and third party software patching program coupled with application whitelisting and a heavy reduction in administrative accounts.