Zeusbot/Spyeye P2P Updated, Fortifying the Botnet

We blogged about a parallel Zeusbot/Spyeye build near the end of last year that introduced some improvements in the botnet, moving the network architecture away from a simple bot-to-C&C system and introducing the beginnings of a peer-to-peer model. This new variant new uses P2P communication exclusively in order to keep the botnet alive and gathering information.

Previously, every compromised computer was a peer in the botnet and the configuration file (containing the URL of the C&C server) was distributed from one peer to another. This way, even if the C&C server was taken down, the botnet was still able to contact other peers to receive configuration files with URLs of new C&C servers.

With the latest update, it seems that the C&C server has disappeared entirely for this functionality. Where they were previously sending and receiving control messages to and from the C&C, these control messages are now handled by the P2P network.

This means that every peer in the botnet can act as a C&C server, while none of them really are one. Bots are now capable of downloading commands, configuration files, and executables from other bots—every compromised computer is capable of providing data to the other bots. We don’t yet know how the stolen data is communicated back to the attackers, but it’s possible that such data is routed through the peers until it reaches a drop zone controlled by the attackers.

While these changes make the botnet more resistant to takedown, and equally more difficult to track the attackers behind it, it also provides another major benefit to the attackers. Zeustracker is a site which has had considerable success in tracking and publishing IP block lists for Zeus C&C servers around the world. With Zeus switching to P2P for these functions means that the site would no longer be able to produce exact Zeus C&C IP block lists.

No need for C&C?

Having to rely on a C&C server is a limitation. It means that it can be taken offline, and that the botnet herders can be tracked. This was still a flaw in the initial P2P version of the bot—by simply black boxing the bot executable, one could observe the C&C server being contacted. It seems that the botnet herders have addressed this issue—the control messages that were going to the C&C server are now going to the P2P botnet itself. Of course the peers are other compromised computers, so they cannot be taken offline. Nor they can be related (in most cases) to the guys behind the botnet.

Figure 1: The C&C paradigm has shifted from central server to botnet

More UDP, less TCP

Another noticeable update is that communication has shifted more and more to UDP. As we have previously discussed, the bots would contact each other by using a sort of homemade UDP handshake. If successful, this would cause the bots to exchange TCP data, such as configuration files, list of other peers, etc. However, TCP communications are easy to track and dump, and the bot does not perform any authentication on the packets exchanged, so anyone can impersonate a bot and successfully communicate with other bots, downloading stuff like configuration data.

In this new strain, the data exchange is also now happening in UDP. Given the stateless nature of this protocol, it is more difficult to capture and extract data from bot communications.

Figure 2a: Older version using TCP to exchange configuration files

Figure 2b: The new version exchanges all data in UDP

Changes in the compression and encryption

The encryption used by the bot was more or less the same as the one used by the “standard” Zeusbot strain. The data is compressed, each byte is XORed with the preceding byte, and then RC4 is applied.

With the new strain the data is still encrypted with RC4 and the XOR byte-with-preceding-byte is still there, but there is now another added layer: a byte-per-byte XOR applied to each block of the configuration, where the encryption key is calculated with the following code:

Figure 3: The new encryption layer code

This corresponds to the simple formula:

 XorKey = ((BlockSize << 0x10) | BlockId) | (XorSeed << 8) 

Once you get past the decryption layers, the last thing to get rid of is the compression of every data block. The earlier version of the bot was using Nrv2b compression, while this new variant has switched to Zlib 1.2.5.

Each bot is a Web server

As explained above, the control messages that were previously handled by the C&C server are now handled by other peers in the botnet. These messages are exchanged through HTTP, so the bot has been updated to include nGinx, an open source, minimal Web server. With this, every bot is capable of handling HTTP requests, meaning it can perform C&C functionalities.

Figure 4a: The older version used standard HTTP POST requests to C&C servers

Figure 4b: The new version sends POST requests to a peer, using a random TCP port

Having the bots host a Web server is not a novelty in the threat landscape. We have seen the Waledac/Kelihos bots already using this technique to exchange data and expose malicious content in order to spread itself.

Zeusbot distributing malware?

One interesting thing that we also observed regarding this new variant is that the Zeus botnet has been distributing malware. The bots communicate with other peers, issuing HTTP requests to download and run two executables. These executables are hosted by other peers in the botnet, and after analysis we discovered they are a fake antivirus risk and a proxy engine. This is unusual; we don’t have records of Zeusbot distributing other malware, although it is technically capable of doing so.

So, is there no C&C anymore?

Well, it seems that the cybercriminals removed (or at least reduced) the dependency the bots had on the C&C server. Still, this does not mean it’s completely gone—the bot may still decide to contact a C&C server under specific conditions (e.g. when there is stolen data to communicate back to the attackers). Analysis of the threat is still ongoing and this is our main point of focus at the moment.

If they managed to completely remove C&C servers then this can be considered a step towards strengthening the botnet. If it only operates through P2P, it becomes nearly impossible to track the guys behind it. Again, analysis is still ongoing, so we are working on uncovering this part of the mystery to figure out the full picture.

Zeus’s main infection vector is emails containing malicious attachments, pretending to look like documents. As usual be wary of emails received from unknown recipients, and never to open files received from unknown sources.