This blog post is the fourth installment in our ongoing series of articles exploring the crypto systems commonly found in various DDoS malware families. Previous subjects have included Armageddon, Khan (now believed to be a very close “cousin” of Dirt Jumper version 5), and PonyDOS. Today we’ll be diving deep into the details of the DarkComet RAT’s crypto. Over the last several months, we have encountered a large number of unique DarkComet samples – over a thousand and counting. DarkComet, also known as Trojan.Fynloski, is primarily a general purpose remote access trojan (RAT). It’s capabilities support quite an extensive laundry list of mischief, including but not limited to key logging, web cam (and sound card) spying, deleting victim files, scanning ports, hijacking MSN sessions, etc.
Above and beyond these standard RAT features designed for general purpose mayhem, the malware includes DDoS capabilities as well – hence our interest in reversing its communications so that we can keep tabs on whom the DarkComet botnets are attacking. In fact, it is believed to have recently been used as a DDoS weapon by supporters of the Syrian regime against opposition forces in the ongoing Syrian uprisings; TrendMicro has a nice article on this topic.
This article builds on the reversing work documented in the excellent DarkComet analysis by Laura Aylward of Contextis. The report provides a full description of the important disassembly blocks that implement DarkComet crypto and, as usual, a Python module for encrypting and decrypting DarkComet communications. Conceptually, the core encryption engine used by DarkComet is very similar to that used by PonyDOS, although there are some important differences in terms of key strings, and DarkComet lacks the cryptographic hashing steps used by PonyDOS.
As described in the report, DarkComet supports the use of a custom password to secure its bot-to-C&C communications. When a new bot binary is built, this password is encrypted using a standard key string which varies with each version of DarkComet; for example, version 2 uses #KCMDDC2#-890, version 5 uses the string #KCMDDC5#-890, etc. The encrypted password is stored as a resource named PWD; other important bot parameters are also encrypted and stored as resources, such as the C&C server hostname and port (in the NETDATA resource) and the server ID (in the SID resource.)
Upon initialization, a DarkComet bot will use its standard (version-specific) key string to decrypt these resources. Once it has decrypted the PWD resource, it will append this custom botnet-specific password to the standard key string to yield the final key that is used for securing communications with its C&C. So for example, a version 5 DarkComet botnet that uses the default password (0123456789), would end up using #KCMDDC2#-8900123456789 as its comms key. If the botmaster chooses to not provide a password when building his/her bot binary, the comms will be encrypted using just the standard version-specific key.
The encryption mechanism used by DarkComet is relatively decent compared to many other malware families; alas, the same cannot be said of its DDoS technology. Due to several catastrophic bugs in DarkComet’s HTTP flooding routines, described in detail in the report, the malware’s DDOSHTTPFLOOD application layer attack does not even manage to come close to producing RFC-compliant HTTP flooding requests. Instead, the traffic it generates is essentially equivalent to a very weak volumetric TCP flood.
A complete review of the crypto system used by DarkComet, with Python re-implementation, is available here:
Report: It’s not the end of the world: DarkComet misses by a mile
This completes the fourth installment in our ongoing series on breaking the crypto systems used by contemporary DDoS malware families.
Leave a reply
