Recently, Symantec observed a modified variant of Zeusbot/Spyeye which uses peer-to-peer (P2P) architecture to communicate. The original Zeusbot communicated directly with its C&C server to download configuration data and upload stolen information. This was a major point of failure for the bot because the C&C server could be blocked or taken down, and the attacker would lose control of the botnet. The bot did have a fallback strategy: if the C&C server was down it generated pseudo-random domain names to contact. The attacker could of course predict those domain names and register one in order to gain back control of the bot, but the solution was not very efficient. (Terminology note: although we use the term “C&C” for the main server controlled by the attackers, this server is not a typical C&C in its functionalities, but is mainly a collector of information from the drones.)
To overcome these limitations the attackers have now decided to use P2P. This modified variant of Zeusbot/Spyeye contains a list of IP addresses to contact. These IPs are not servers; they are other infected clients (peers). These clients provide configuration data, which in turn contains the URL of the main C&C server. In this modified way, even if the C&C server is taken down, the P2P network remains alive and can be fuelled with a new configuration file pointing to a new URL for a new C&C server. Can the P2P network be shut down? No (at least, not easily). The IP addresses in the P2P network cannot be blocked because, in most cases, they would be normal broadband IPs (home users and work computers, for instance) and blocking them would disrupt legitimate network traffic. Also, the list of peers can update so frequently that tracking them proves difficult. Using a P2P network this way is more resistant than just a single C&C URL, and can considerably prolong a botnet’s lifetime.
Here's how it works: When run, the bot injects itself into the “explorer.exe” process, and tries to contact all the IP addresses one-by-one using UDP. This communication protocol is not complex. It can exchange several data packets with specific codes and meanings and, to identify the communications, have the peers use SHA-1 codes to keep track of the data.
To initiate a communication the bot sends out a “portknocking” data packet that contains a header with the SHA-1 of the infected machine and the SHA-1 of the contacted machine. Every infected machine (peer) has its own unique identifier SHA-1 and every bot contains a list of SHA-1 : IP couples which represent unique hosts on the P2P network. After the portknocking packet is accepted by a peer, the reply to the portknocking includes a new list of peers (SHA-1 : IP couples again). This keeps the P2P network updated with a list of new machines.
More UDP packets may follow the portknocking, exchanging different data (the purpose of which is still under investigation).
Figure 1: Communication
When the UDP communication is complete, the bot will then proceed to contact the peer through TCP. At this stage the bot can receive both a configuration file or an update of the bot itself. The decrypted configuration data contains the address of the C&C server which the bot contacts through a simple HTTP POST request. The bot then sends data about the infected machine (name of the machine and other information) to the C&C server.
Interestingly, the SHA-1 of the infected machine is not communicated at this stage (in our tests it was not sent to the C&C at any time). This may mean the C&C server is not involved in controlling the peers (e.g. collecting of all SHA-1 and updating the list of available peers) and therefore the P2P network would be completely autonomous.
We have found several samples in the wild which all seem to originate from a single source. These samples are all packed with the same techniques, and the binary code of the unpacked virus is almost identical (differing in only the smallest of details). This leads us to believe these samples are coming from the same source code, but are recompiled with small changes. We suspect those responsible for spreading this new variant may have access to the source code and upgraded the bot with all the new features. Our samples also all shared the same RC4 substitution box used to decrypt configuration data and we also ran some different random samples and the configuration data they downloaded is similar in all cases. All these details indicate this Trojan seems to be a private build from those who had access to source code and want to target specific websites (lots of Italian ones).
We first observed this threat on September 13, 2011. This date also matches the time-date stamp of the first samples found, when we believe the variant started spreading. At the time of writing this blog, the threat does not seem prevalent with only a limited number of samples in the wild (this may change in time, of course). This does not mean the botnet is dead: the P2P network is alive and we have decoded the latest data from the configuration files which contains the frequently updated C&C server address (the C&C server is currently active using a November-registered domain name). In total we observed 327 unique peers, so an estimation of the number of infected machines could be anywhere from 500 to 1000.
Figure 2: Infection geographical distribution
The modified variant of Zeusbot/Spyeye which uses a P2P network is indeed an improvement, but comes with drawbacks as well. The communication protocol lacks proper authentication so a rogue client may connect to the network and communicate with peers. The configuration file is not authenticated, since it is encrypted with a symmetric algorithm, meaning a rogue configuration file would be easy to forge. Any infected client can become part of the list of peers actively exchanged by the drones. A rogue client may infiltrate the P2P network, forge a rogue certificate, and distribute it to other bots—which means the rogue would be able to specify a new C&C server and hijack the entire network.
At this stage we cannot tell if this variant will become a mainstream implementation of the bot or simply die off. We will keep an eye on it in order to detect all new variants. It has been reported that this threat has been spreading through spam emails and drive-by download exploits, so, in order to mitigate the risk of infection, we recommend users keep their computers updated and beware of email from unknown or unverified sources.
Additional details from the analysis are available to our DeepSight subscribers.