The analyzed bot:

Despite the novel way of C&C-communication, the other features of the analyzed bot are quite common these days. It offers several possibilities for DDoS attacks, can download and execute other malware, and can act as SOCKS proxy to anonymize the attacker.
 

What is it about?

One of the biggest challenges for botnet owners is the protection of Command-and-Control traffic. C&C traffic is required to give orders to the "zombies", the infected computers that are part of the botnets. Generally, up to now, two approaches existed for C&C traffic: Either a central control server is put somewhere on the Internet or Peer-to-Peer-networks (short: P2P) are built up to ensure the chain of commands.
 

One central C&C server:

Central control servers have a big problem: Regardless of the underlying protocol, they are a "single point of failure". The servers can be taken over by authorities, and thus the malware can be uninstalled from the zombies. It is possible to conceal the server, e.g. by having a hidden algorithm that changes domain names on a daily base; but these algorithms can be reverse engineered.

The P2P architecture:

An alternative is the usage of classic P2P networks. P2P networks became (in)famous with the rise of Napster, which used to be a service where every user could send and receive music from and to other users. Every user acted as client and server simultaneously, hence the term Peer-to-Peer.

Malware adapted to this scheme by giving every zombie the ability to issue commands to other zombies. The botnet owner issues the command to a handful of zombies, and these zombies propagate the commands to other zombies, and so on and so forth. Even though this seems to be more sophisticated than the direct client-server-communication, it is anything but perfect.
Zombies are often located behind routers, meaning that they effectively cannot act as a server, because the routers do not allow incoming traffic by default. Also, the protocol has to be especially designed for the respective bot, which results in a great implementation effort.

Furthermore, there are security issues the botnet owners have to think about: By design, every zombie programmed for the P2P-communication has the ability to issue commands to other zombies. Therefore authorities or other cybercriminals could issue commands to conduct a hostile takeover of the botnet. Generally, it is possible to authenticate messages, but botnet owners often find it hard to implement this or are not willing to put that much effort into these authentication mechanisms. This resulted in several botnet takedowns and even takeovers in the last couple of years.
 

The next step made – using the Tor network

The next step in evolution is the usage of the Tor network. Tor is generally known as web anonymization service for end users, but Tor offers more than that: “Tor makes it possible for users to hide their locations while offering various kinds of services, such as web publishing or an instant messaging server.”

In this particular case, the creators of the malware decided to build an IRC server as hidden service.

 

This gains the botnet owner several advantages:

• The server is anonymous and thus cannot point to the botnet owners’ identity.
• The server cannot be taken down easily.
• The traffic is encrypted by Tor, so it can’t be blocked by Intrusion Detection Systems.
• Tor traffic usually cannot be blocked altogether, because there are also legit use cases for Tor.
• The bot creator does not necessarily have to generate a custom protocol, but can use the known and reliable IRC protocol.

Besides these advantages, it has to be noted that malware like this suffers from the latencies that come with the Tor network. In other words: Tor tends to be slow and unreliable, and inherits these flaws to underlying botnets. Also, while this traffic adds a lot of security to the botnet communication, the malware itself still can be blocked by AV software using signature- and behavior-based detection mechanism.
 

Want information about the analyzed sample? Contact: samplerequest (at) gdata.de