n the autumn of 2011 we observed new malware infections, which looked similar to Zeus. Subsequent analysis of the malicious software mechanism start up, the process of hiding and storing of configuration indeed verified that it was ZeuS. However, monitoring of infected machines failed to uncover the characteristic communicatation with a C&C. After closer examination it appeared that the sample was probably a new version based on the source code of ZeuS that was accidentally made public.
In the new version of the Trojan, the authors focus on eliminating the weakest link – a centralized system of information distribution.
Previous versions of Zeus were based on one (or few) predefined addresses which were used for botnet management. This allowed for relatively easy tracking and blocking of servers, thus rendering the botnet useless. However, the analysed variant of the Trojan used two new channels of communication to receive orders (figure on right):
- Komunikacja w sieci peer-to-peer
- Mechanizm Generowania Domen
This variant has been analyzed to some extent by other researchers before – there is information on the web on the new variant of Zeus (eg abuse.ch ), however – based on our knowledge – previous research has focused on registering and monitoring traffic to Zeus domains. In our work we focus on understanding the P2P network communication mechanisms, mapping out the network, and monitoring the exchange of information in this particular network.
Information sharing over the Zeus-peer-to-peer (ZP2P) network
 |
| rys.1: Wizualizacja sieci ZP2P (10 000 węzłów) |
In the case of a model based on central (one – or many) point of management, it is possible to identify machines used for command & control. The new mechanism for distributing information is based on the direct exchange of data among infected computers – a model of communication based on peer-to-peer networks. The fact that there is no central management node in this model makes it much harder to find which computer is used to distribute new orders – and the blocking of the information exchange channel is virtually impossible. This is well illustrated by the graph in Figure 1. You can see that the presented network does not contain any central point (single or multiple), and the connections between computers are random.
How does the ZP2P network operate?
The network most likely is based on Kademlia protocol standard. A single computer (node) in ZP2P network is identified by a unique identifier UID – which is generated during the first run of malicious software. Each of the computers belonging to the ZP2P has a “table of neighbors” stored in memory. This array contains a list of about 30 neighboring nodes in the ZP2P network – their UID, IP address and UDP port number. This list is used to exchange binary data and information.
In the ZP2P network, we can distinguish two types of communication:
- The exchange of administrative information (using UDP):
- (QV) Exchange of information about version of the configuration files
- (QN) Exchange of information about the nodes in the “table of neighbors”
- The exchange of binary data (using the TCP protocol)
- Distribution of new configuration files
Charts 2 and 3 show the distribution of port numbers used for network communication by ZP2P on the network we mapped.
|
|
If the case of message type QN, only 10 records from the “table of neighbors” are sent back to client. This type of communication is dedicated for upgrading the local “table of neighbors”. After the query type QN, the bot saves information about nodes whose UID is similar to the bot UID (XOR metric) on a local computer.
Messages of type QV are used for checking and the propagation of information about new versions of configuration files. If the node that performed the query QV has an older version of the configuration than the version given in response to this query – the bot performs a TCP connection to a remote computer asking for a newer version of the configuration.
Charts 4 and 5 show the distribution of the number of children and the number of parents in the ZP2P network. The data comes from the analysis of responses to QN queries during a 3 week period. The number of children (the number of entries in “table of neighbors”) may exceed the value 30, because (as already described), the table may be frequently updated.
|
|
ZP2P Network Monitoring
In the CERT Polska laboratory, we manage to do a mapping of a ZP2P network by monitoring the response to type QN queries. Collected IP addresses are plotted on a map:
 |
| Mapa gęstości ilości komputerów zainfekowanych nowym wariantem trojana |
The DGA mechanism
If the communication mechanism of the ZP2P network will be blocked (eg by blocking the appropriate TCP and UDP ports on a firewall) – the bot will automatically switch to the backup communication channel – DGA. DGA mechanism is another feature implemented in the new version of the Trojan. It significantly impacts the difficulty of finding and the cutting-off of the miscreants behind the botnet.
The DGA allows for the generation of a long list of domain names based on specified parameters, and subsequently of attempts to communicate with each of the generated domains. DGA mechanism parameters are hidden inside the Trojan code – and are known only to the botmaster. The botmaster can manually generate such a list, select one position, register the selected domain, and wait for connection attempts from infected machines.
 |
| rys. 6 Generowanie zeusowych domen |
Zeus-DGA
In the case of this Zeus botnet, the parameter for the DGA mechanism is calculated from the current date. The list contains over 1000 domains and changes every 7 days. Each name consists of a string with a length of 32 to 48 chars, and one of TLDs: ru, com, biz, info,net or org. It is worth noting that the domain names do not contain the “-” sign. Below is a regular expression for searching ZeuS domains in log files:
 |
| rys.7: Dodane wyjątki w konfiguracji systemowego firewalla |
How to recognize a new ZeuS infection?
The presence of a new variant of Zeus on the computer can be identified primarily by monitoring network traffic. As shown in Figure 8 – by using TCPView, it is possible to see the new open TCP and UDP ports of the explorer.exe process. In addition – to allow communication with the ZP2P network – the Trojan adds new rules to the system firewall. As shown in Figure 7, there are the two new exceptions to allow connections to specific TCP and UDP ports. The range of these ports can be read from plot 2 and 3
 |
| rys.8: Otwarte porty TCP i UDP wykorzystywane do komunikacji P2P |
UPDATE:
MD5 of analyzed samples:
Skróty MD5 analizowanych próbek :
8DCAB7400401F139DE582F6A0E2111F0
974A291A0F547FD39584DE346B6079F5
C37BD23F39EAF1DAEE4B63B81AD6FD02
