, pp.55-59 http://dx.doi.org/10.14257/astl.2014.64.14 Realtime C&C Zeus Packet Detection Based on RC4 Decryption of Packet Length Field ChulWoo Park 1, HyoSung Park 1, KiChang Kim 1 1 Information and Communication Engineering Dept., Inha University {adolmn@naver.com, mongsiry013@hanmail.net, kchang@inha.ac.kr} Abstract. Zeus is one of the will-published malwares. It infects PC s via emails or vulnerable applications and extracts private information such as user ID, encryption key, etc., causing considerable damages. Zeus, when it was first found in 2006, started as a C&C (Command and Control) style botnet and is now moving to P2P (Peer-to-Peer) style. This paper describes techniques to detect and classify C&C Zeus packets, however the suggested technique should be able to be adapted to P2P Zeus packets also. Keywords: Zeus, Malware, Botnet, C&C, RC4, Report packet 1 Introduction Malware is a short form of Malicious software. Malware is widely spread in the internet and causing various problems such as exposing personal information. Zeus is one of such malwares and is especially notorious for its role in financial exploiting feature. Zeus infects a set of numerous PC s or Bots and connects them into a Botnet. The first Zeus-infected PC s found in 2006 have communicated through C&C server, but now they are evolving into P2P network [1]. This paper analyzes the C&C Zeus source code (Ver. 2.0.8.9) to identify the characteristics of a Zeus packet. We were able to establish a technique with which we can detect a Zeus packet in real time. 2 Zeus Report Packet Structure C&C Zeus client has to send several types of control packets periodically for the server-bot communication. One of them is called Report packet. Report packet is used to send personal information collected in the client to the server and has the structure shown in Fig. 1 and 2. It consists of Header and Body. Header (Fig. 1) contains the entire packet size, number of items, etc. Body (Fig. 2) contains information specific to each item. Zeus packets are transmitted in encrypted format and Report packet is no exception. We capture Report packet and detect whether it is a Zeus packet or not by examining its body size field and compare it with the entire packet size. If they match, there is a high probability that it is a Zeus packet. However in the presence of encryption how can we know the value of body size field? Our technique matches ISSN: 2287-1233 ASTL Copyright 2014 SERSC
body size field with the entire packet size without decryption and, thus, can detect Zeus packet even when it is encrypted. Fig. 1. Zeus Report packet header Fig. 2. Zeus Report packet item 3 Zeus Encryption Algorithm C&C Zeus uses two different kinds of encryption algorithm. One is RC4 and the other is Zeus-specific algorithm consisting of visualencrypt and visualdecrypt [2][6]. Fig. 3 and 4 shows encryption and decryption process in Zeus. Fig. 3. Encryption process in Zeus Fig. 4. Decryption process in Zeus visualencrypt and visualdecrypt algorithm both consist of a successive application of XOR operations. The transmitted packets are encrypted and it is hard to find the corresponding RC4 key. In early Zeus version, the stream key was located in certain location of memory [4], but it is no longer true especially in version 2.0.8.9 which we are looking at. However due to the characteristics of XOR operation, we can extract the portion of stream key used for "body size" as in Fig. 5. First starting with the cipher text for "body size" field, we apply "visualdecrypt" algorithm to obtain "New Text". If we had known the "new stream key" for this field, we could obtain "Plain Text" by XORing "New Text" with it. We don't have it. However because of the duality of XOR operation, we can obtain "new stream key" by XORing "New Text" with "Plain Text". Note that we know "Plain Text" since it is the entire packet length and is reported in the IP packet header. 56 Copyright 2014 SERSC
Fig. 5. Modified Zeus decryption process 4 Detecting Zeus Report Packet The "item" packet shown in Fig. 2 has Item ID in the first 4 byte. This Item ID has many types [2]. Among them, "SBCID_BOT_ID" (ID 10001) is the mandatory item that should be transmitted first. Therefore we can detect Zeus packet by observing whether it has ID 10001 or not at offset 49. In the presence of encryption, since the same client will use the same RC4 key, we can expect the Report packets from the same client will contain the same cipher text at offset 49 if they are SBCID_BOT_ID items. Therefore if a client is transmitting a number of packets that have the same cipher text at offset 49, we can suspect they are SBCID_BOT_ID Report Item packet from the same client [4]. The problem of this approach is that we have to collect a fairly large number of Report packets before we can say the possibility of Zeus infection. Our technique is superior in that even with two Report packets it can predict the presence of Zeus infection. It extracts the 4-byte cipher text at offset 21 in the Header packet and collect all Item packets of this Report packet. The total size becomes the plain text and by XORing these two 4-bytes after proper conversion of them through visualencryption or visualdecryption, we can obtain the "new stream key". If we can find the same "new stream key" for two different Report packets from the same client, we can say with high probability that the client is infected with Zeus. 5 Experimental Results In this section, we show an example that explains the process of producing the "new stream key". Copyright 2014 SERSC 57
Fig. 6. Experimental results Fig. 6 shows three different Report packets. The packet lengths are all different: first one has 0x527 bytes, second one 0x15a bytes, and the last one 0x57c bytes. We extract the "body size" field of each packet, apply visualdecrypt and XOR it with the size to obtain the "new stream key". For example, for the first packet, the cipher text for the "body size" is 0x2e22c8c6. After applying visualdecrypt, it becomes 0xe30cea0e. XORing it with the packet size, 0x27050000, we obtain 0xc409ea0e, the "new stream key". Now when we apply the same process for the second and third packets, we obtain the same "new stream key", 0xc409ea0e as shown in Fig. 6. We cannot recover the whole stream key used in encrypting the entire packet. However at least we were able to recover the portion of the stream key that is used to encrypt the "body size" field. Now if two different Report packets from the same client contains cipher text at offset 21 in their Header packets that produce the same "new stream key" when the above procedure is applied, we can be sure with a very high probability that the client is infected with Zeus. 6 Conclusion Since 2006, Zeus is infecting a large number of PC's causing various security problems. Zeus packets are not easy to detect since they are encrypted and show random pattern. This paper presents a technique that can detect Zeus packets with relatively small number of collected packets. The technique is based on the observation that certain field of Zeus packet contains packet size information and that when this field is encrypted we still have the corresponding plain text for it by computing the entire packet length directly. The weakness of RC4 allows us to detect Zeus packets via XORing the cipher and plain text of this field. This paper shows that this technique is effective and can detect Zeus packets even in the presence of encryption. 58 Copyright 2014 SERSC
References 1. Binsalleeh, Hamad, et al. On the analysis of the zeus botnet crimeware toolkit. Privacy Security and Trust (PST), 2010 Eighth Annual International Conference on. IEEE, (2010) 2. https://github.com/visgean/zeus 3. http://en.wikipedia.org/wiki/rc4 4. Riccardi, Marco, et al. Titans revenge: Detecting Zeus via its own flaws. Computer Networks 57.2. 422-435 (2013) 5. Klein, Andreas. "Attacks on the RC4 stream cipher." Designs, Codes and Cryptography 48.3. 269-286 (2008) 6. Wyke, James. What is Zeus?. Sophos, May (2011) 7. Steel, Graham. Deduction with XOR constraints in security API modelling. Automated Deduction CADE-20. Springer Berlin Heidelberg, 322-336 (2005) Copyright 2014 SERSC 59