kuluoz: malware and botnet analysis · 2. introduction this report describes a family of malware,...
TRANSCRIPT
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