3 Abstract Zeus or Zbot is one of the most notorious and widely-spread information stealing Trojans in existence. Zeus is primarily targeted at financial data theft; its effectiveness has lead to the loss of millions worldwide. The spectrum of those impacted by Zbot infections ranges from individuals who have had their banking details compromised, to large public order departments of prominent western governments. We will explore the various components of the Zeus kit from the Builder through to the configuration file; examine in detail the functionality and behaviour of the Zbot binary; and assess emerging and future trends in the Zeus world. Introduction Zeus (also known as Zbot) is the name of a toolkit used to create a particular strain of information stealing Trojans. The bots created by the kit run silently in the background on compromised computers, harvesting information and sending it back to the bot herder. The main focus is to steal online banking details and other login credentials but the range of different types of data theft is extremely broad. The kit is obtained on underground forums with older versions available for free and the newest, fully-featured versions costing several thousand dollars. The Zeus kit is very simple to use, requiring little technical knowledge. As a result, huge numbers of independent Zeus-created botnets exist, all with their own controllers. A by product of this is that we in the AV industry see huge numbers of Zbot samples that seem to bear no relation to each other, as each botnet owner packs and obfuscates their samples in different ways. Some of these self-contained botnets have been hugely successful with stories in the press of some operations managing to steal hundreds of millions of dollars. Brief History of Zeus Although the overall aim of Zbot (that of information theft) has remained the same since it first emerged, there have been several noticeable changes along the way in how it achieves that goal. The earliest versions were notable by the consistent filename that the bot executable was given when first run on the target system and the filenames given to the data files. Early samples would use the following filenames for the executables: ntos.exe, oembios.exe, twext.exe Data files were stored in the following directories: <System>\wsnpoem <System>\sysproc64 <System>\twain_32 The next major version predominantly used sdra64.exe for the executable name and stored the data files in <System>\lowsec. The most recent version of Zbot stores the executable file with a random filename in a newly created, randomly named folder in the Application Data folder of the executing user. 2

4 Components of Zeus The Builder Each prospective Zeus botnet owner must create their own bot executables that they will distribute to their victims. To do this the Zeus kit includes a builder (Fig 1). Each customer uses the builder to create both the encrypted configuration file and the bot executable that is specific to the customer. The executable will be unique for each customer (even if two customers use exactly the same version of the builder) due to the configuration file URL and the key needed to decrypt the configuration file that are embedded into the executable. First the configuration file needs to be built which includes all the essential information that makes the bot do anything useful (more in the next section), including the URL where this file will be located. The file must first be edited with the bot owner s settings and then built using the Build config button. The builder will then convert the text file into the binary format expected by the executable, compress and encrypt it. The botnet owner then places the encrypted file at the URL they specified during the build, to be retrieved by the bot upon execution (Fig 2). Fig 1. Zeus Builder Fig 2. Zeus Build config 3

5 Then the executable can be built with the Build loader button. The Builder will embed the information needed to retrieve and decrypt the configuration file into the Zbot binary before packing it with its own custom run-time packer. Generally speaking, Zeus customers will then pack the executable again with some other packer (Fig 3). The Configuration File The configuration file component of the Zeus kit is absolutely essential if the bot is to do anything useful. It is a separate entity to the executable, downloaded during execution. This file contains (amongst many other things) the address to which all the stolen data is sent. If the configuration file cannot be retrieved then the bot will not know where to send its stolen data. It is divided up into sections that start entry with the two main being entry StaticConfig and entry DynamicConfig. These two sections deal with the settings that will be hardcoded into the binary and the settings that will be written into the configuration file and downloaded at runtime. The static options include timing options (how long to wait between attempting to download the config file etc), the URL from which the configuration file is downloaded, and a URL that is used to check the external IP address that the bot is phoning home from. These will be written into the binary when it is distributed. The format the file takes is a series of blocks that enable and customise the various functionalities that Zbot offers. The following screenshot shows the file before it is packaged by the builder, as you can see from the top of the file this is version (quite old, we have now seen beyond version 2.1)(Fig 4). Fig 4. Configuration file Fig 3. Build loader 4

6 The dynamic options mainly centre on what particular web addresses the bot owner wants to target but there are also several housekeeping entries, including: a URL from which a new Zbot executable will be downloaded a URL to which stolen data is sent back a URL at which a further configuration file can be downloaded The other dynamic options include: A set of URL masks that enable or disable logging for those URLS A set of URL pairs where one URL is redirected to the other URL A group of URL s from which TAN s (Transaction Authentication Number) will be harvested A set of IP/domain pairs that will be written into the hosts file to hijack DNS requests. A set of URL masks each with a corresponding block of HTML that will be injected into any page whose request matches the URL mask (WebInjects) The last item is where the Zeus bot owner can really capitalise financially on their installation. The owner can inject any data they wish into any webpage such as extra fields in online banking web pages that ask for ATM pin numbers and social security numbers. The following screenshot shows a typical item from the WebInjects section (Fig 5). This shows that the code snippet will be injected into any URL that contains https:// where the code will be injected (after the data in data_before ), and the code itself which is extra fields in the form requesting ATM PIN etc. All the dynamic configuration data goes into the configuration file that is stored on the server. The bot will then periodically query the URL for the file and process the data it contains. In this way the bot owner can easily change the behaviour of the bot by uploading a new configuration file to the server. The Exe File The exe file that is built by the builder component is to be deployed by the botnet owner. Different Zeus kit customers using the same version of the kit will produce almost exactly the same exe file, with the most important difference being the location of the configuration file which gets embedded into the binary by the builder. This is essentially the only thing that differentiates one Zeus kit created botnet with another the configuration details. The functionality and the behaviour will always be the same. The Server The server component of the Zeus kit is a collection of php scripts that allow the owner to monitor the status of their bots, issue commands to them and retrieve the information that they have collected. The interface is very user-friendly and a vast array of information about the botnet is available to the owner. Fig 5. WebInjects section 5

7 Functionality of the Zbot Binary Execution Overview In very general terms Zbot performs the following actions: Copy itself to another location, execute the copy, delete the original Lower browser security settings by changing IE registry entries Injects code into other processes, main process exits Injected code hooks apis in each process Steals several different type of credential found on the system Downloads config file and processes it Uses api hooks to steal data Sends data back to C&C The last two major versions of Zbot have several distinct differences in their execution. The previous version copied (I use term copy loosely here as changes are made to the binary which I will come back to later) itself into the system directory, usually using a name along the lines of sdra64. exe, created a folder, also in the system directory, typically called lowsec that contained the downloaded configuration file and temporary file holding stolen data while it was waiting to be sent to the C&C server. This version added an entry to the Userinit value of the HKLM\Software\Microsoft\ Windows NT\CurrentVersion\Winlogon registry key, in order to run on system startup. This version also hooked several ntdll.dll apis including NtQueryDirectoryFile in order to hide its files. This usermode rootkit is not present on the more recent version. The version I will concentrate on most (version 2), copies (again loosely used) itself to the user s Application Data folder using a randomly generated filename and directory name. The temporary data file is also stored under %AppData%, again with random names, and the configuration data is downloaded into the registry rather than onto the disk. This version creates a runkey under HKCU. The use of Application Data and HKCU over the system directory and the Winlogon key means that many different Zbot botnets can infect the same machine, and different users can be individually infected. Anti-Checksum Based Detection For quite some time Zbot has used techniques to make full file checksum based detection less than effective. Pre-version two a variable amount of random data was appended to the file when it was copied into the system directory (hence loose use of the term copy ). Version two uses a more complicated technique to ensure that the dropped file will not have the same checksum as the original dropper. When the version two executable copies itself to the user s Application Data directory, a small (just under 0x200 bytes) block of encrypted data is embedded into it. This block contains (amongst other things) the path that the file has been dropped to and a GUID generated from the disk that it is on. Because the pathname is randomly generated this block will be different each time the file is executed, thus making it extremely unlikely that two identical files will be produced. 6

8 Detailed Run-Through of Zbot Execution For this detailed run-through I will concentrate on the more recent version of Zbot (2 and later). Specifically the sample I m using (sha1: 014e f169e61074daef35e2f14267bbb) gives its version as Unpacking Although I won t go into the details of the various packers used by Zbot, it is worth mentioning that the file will almost always be packed. The builder itself will pack the file with its own custom, packer, but it is rare that a Zbot customer will not pack the file again with some other packer. It Begins Initially, the sample will resolve and store some imports from ntdll.dll, retrieves some general information about itself PID, OS version, whether it s running under WOW 64, process access level; then it will check its command line arguments. The sample will run just fine without any arguments but there are a few that can be supplied, the most interesting of which is probably -i which will cause the sample to display a message box giving information about the sample (including version) and terminate (Fig 6). Dropper or Droppee? The Zbot file will then establish whether it is the dropper (in which case it needs to copy itself to %AppData%) or if it has already been dropped (in which case it needs to inject itself into other processes). First, the sample reads its own executable from the disk into dynamic memory. It then finds the address of the start of the first section named.data and copies 0x200 bytes from that location to the heap. These bytes are then decrypted using RC4 and the final dword from the decrypted RC4 block is used as a flag to indicate whether we are the dropper or droppee. To begin with we will assume we are the dropper. Decrypt the Dropping Routine A mutex is then created with a cryptographically derived name, designed to be unique so that only this bot sample will create a mutex with that name (this is a common pattern throughout Zbot s execution). This ensures that only one sample from this botnet can run at once on this machine, but, importantly, allows samples from other Zeus kit owner s botnets to coexist on the same machine. Fig 6. Message box 7

9 Now the routine that will create and write the dropped file is decrypted. The encryption is byte-wise XOR with a rotating 4 byte key. The key and the size of the data to decrypt is obtained from the 0x200 byte block that was decrypted earlier. As we will see, this 200 byte block is replaced on the dropped file so the dropped file will not hold the key to decrypt this routine. Execute the Dropping Routine A randomly named registry key is created under HKCU\Software\Microsoft. This is where the configuration data will be stored. A new 0x200 byte block is then constructed that will overwrite the existing block in the file. This block will contain important information that the dropped file will need in order to successfully execute and includes the following: A string that identifies the infected machine comprised of the computer name, OS version, OS install date, the OS DigitalProductId. A GUID identifying the drive that the file will be dropped to written to and read from the registry, and to encrypt the stolen data. The path after %AppData% that the dropped file will reside at The name of the registry key under HKCU\Software\Microsoft This block is written over the top of the old block and the file is written to the randomly generated path under %AppData% and given a filetime at a random date in the past. Pass the Baton The newly created file is then launched and a batch file is dropped and executed that will delete the dropper. The Droppee If we are running as the droppee then the first 0x1e6 bytes of the embedded 0x200 byte block is decrypted again, this time using a different RC4 key than used to check if the sample is the dropper or the droppee (but the same key that was used to encrypt the block when the dropper was creating the droppee). An RC4 encryption key used to encrypt/ decrypt the config data when it s Dropper Decrypt 0x200 byte block Check DWORD value at offset 0x1E6 Decrypt file creation routine Write and execute new file Write and execute self-deletion batch script End Droppee Decrypt 0x200 byte block Check DWORD value at offset 0x1E6 Decrypt first 0x1E6 bytes of block using different key Verify block running on same system as created on Inject into other processes Continue 8

10 The same algorithm used to generate the GUID for the drive is executed and checked against the decrypted value, as is the pathname of the currently running executable against the values inside the decrypted block. If either of these checks fail then the program will terminate. This ensures the sample can only be run from the same location that it was dropped to. The sample then writes its image into the address space and every process that it has permission to and a new thread is started inside that process. The main thread will then call ExitProcess and the focus of execution moves onto the injected threads. The injected thread will first hook a large number of API s in the injected process. These API hooks are how Zbot intercepts and alters information flowing through the machine. The process name is then checked and if it is one of dwm.exe, taskhost.exe, taskeng.exe, wscntfy.exe, ctfmon.exe, rdpclip.exe, explorer.exe then a flag is set that indicates more threads will be launched from within this process (more on these later). The injected thread will then go about stealing certain information that is stored on the victim s hard drive. This data includes: Data stored in browser cookies Any certificates that can be found using CertEnumCertificatesInStore(). Data stored in flash cookies Credential information stored by the following FTP programs: FlashFXPFTP Total Commander WSFTP FilezillaFTP FarManager WinSCP FTPCommander CoreFTP SmartFTP In the most recent version (2.1) data is harvested from several other locations including from programs such as Windows Mail and Outlook Express and from online poker application Full Tilt Poker. 9

11 If the thread has been injected into one of the processes from the above list then several other threads are launched. These threads include: A thread that listens on various ports A thread that downloads and processes the configuration file A thread that monitors the bot s runkey entry in the registry, restoring it if it is removed Configuration File Processing The configuration file URL, along with the RC4 key to decrypt it, is encrypted and embedded in the Zbot binary. Once the thread responsible for downloading the config file has been started it will decrypt the region containing the URL and key and download the file over HTTP. It is then decrypted using the RC4 key and the MD5 of the decrypted file is computed. This is checked against a value inside the header of the decrypted configuration file to ensure the file is as expected and has not been corrupted in transit. Fig 7. Snippet of code The thread will then re-encrypt the configuration data and write it into the registry (under the randomly named reg key under HKCU\Software\Microsoft that was created earlier). When written into the registry the configuration data is encrypted with a different key than was used to decrypt it after the download. The key used is inside the block that was written into the file by the dropper. Here is an overview of the process: 1. XOR decrypt region inside binary 2. Get config file URL and RC4 key1 from decrypted data 3. Download config file and use RC4 key1 to decrypt 4. Verify hash of decrypted data 5. Use RC4 key1 to decrypt block of data written into file by dropper 6. Get RC4 key2 from decrypted data 7. Re-encrypt data using RC4 key2 and write to registry This second RC4 key is also used to encrypt stolen data when it is both stored temporarily on the disk and when it is sent back to the C & C server. Once the configuration file has been downloaded and written into the registry, the same thread will attempt to download any new executable file that the configuration data points to. The following is a snippet of the code that finds the new exe item and downloads the contents (Fig 7). If there is an entry in the configuration file for an updated configuration file URL, the thread will also download and process that. 10

14 Emerging and Future trends There have been several recent developments in the Zeus world that may dictate the future direction that Zbot takes. Murofet, Domain Generation and File Infection In the latter part of 2010 a major new revision of Zeus (2.1 in the binary and configuration file) was released. Amongst the improvements two major features stood out: The phone-home mechanism was updated to use a pseudo-random domain generator. An extra hook was added to NtCreateFile in ntdll.dll that included functionality to infect files with.exe extensions as they were accessed. The Domain Generation Algorithm is time based. The current time is used as a seed to cryptographically generate the full domain. This makes the Zeus botnet much more robust to take-down, as new C & C servers can be used as existing ones are taken offline, without having to update the executable on the infected machine. The new code written to infected files uses the same domain generation algorithm that the Zbot executable uses to contact its command and control infrastructure. The infected files are generally known as Murofet. Each infected file has effectively become a downloader that will re-infect the system with the latest Zbot executable. This strategy increases the scope for infection and makes it more likely that a re-infection will occur if the original Zbot file is detected and removed. SpyEye Merger In late 2010 Brian Krebs [http:// krebsonsecurity.com/2010/10/spyeye-vzeus-rivalry-ends-in-quiet-merger/] reported that there was evidence to suggest on underground hacking forums that the Zeus kit author was retiring and had sold the source code to the author of rival crimeware kit SpyEye. A condition of sale was that the new owner continued to support existing Zeus customers. There has certainly been no let-up on Zbot samples seen in the wild since this announcement so whatever the exact course of future development for Zeus, we are unlikely to have seen the back of it. Conclusion Zeus has grown into one of the most popular and widespread crimeware kits on the market. Its ease of use and effectiveness make it an attractive choice for today s cyber criminals. A Zbot infection can be extremely costly. For an individual, theft of login details and online banking details can be disastrous. For an organization, the impact can be vastly more devastating. The success of Zeus shows that this type of malware, be it in the form of Zeus itself or competitors to Zeus, is only likely to become even more widespread. Clearly, the demand for easy to use, information stealing Trojans is high, and as long as that demand exists there will be those who are willing to fulfil it. 13

16 Version 2.0 This version saw an increase in obfuscation of the RC4 key and an extra level of encryption on top of RC4. This version also saw the configuration data stored in the registry rather than a file on the disk. The easiest way to retrieve the RC4 key and URL to download the configuration file is from the Zbot PE file that is injected into running processes. Once the configuration file has been RC4 decrypted there is an extra XOR decryption on top as follows: for (m = (decsize-1); m >0; m--) { decdata[m] = decdata[m] ^ decdata[m-1]; } The decrypted configuration file consists of a header section then a number of blocks, each with their header indicating what should be done with them. The header contains the following information: Each block has a header containing the following: An identifier field Another field used to indicate if the block is compressed or not Size of the data in the block compressed Size of the data uncompressed If the data is compressed it is done so using unrv2b [http://qa.coreboot.org/docs/ doxygen/src_2lib_2nrv2b_8c_source.html]. Stolen Data Encryption Stolen data is stored temporarily in a file on disk before being transmitted back to the C & C server. This temporary file starts with a DWORD value which is the length of the data chunk, XOR ed with a key embedded in the Zbot PE file, followed by a Zero byte then the RC4 encrypted chunk of data. Then there is another XOR ed DWORD, Zero byte, RC4 ed block of data and so on until the end of the file. Size of the decrypted file Number of blocks Hash of the file 15

ZeroAccess James Wyke SophosLabs UK Abstract ZeroAccess is a sophisticated kernel-mode rootkit that is rapidly becoming one of the most widespread threats in the current malware ecosystem. ZeroAccess ability

PAGE 5 Check Point Malware Research Group HIMAN Malware Analysis December 12, 2013 Researcher: Overview This report is a detailed analysis of the dropper and the payload of the HIMAN malware. This malware

Malware B-Z: Inside the Threat From Blackhole to ZeroAccess By Richard Wang, Manager, SophosLabs U.S. Over the last few years the volume of malware has grown dramatically, thanks mostly to automation and

The Citadel Banking Malware: Capabilities, Development History and Use in Cyber Crime ThreatScape Intelligence Cyber Crime Report November 5, 2013 Version: [1] Key Points Citadel is based on the publicly

CITADEL TROJAN OUTGROWING ITS ZEUS ORIGINS May 2012 As of April 30th, 2012 the Citadel Trojan was at its fourth upgrade with Version 1.3.4.0 already in the hands of its customers. Citadel s features, bug

Automating Linux Malware Analysis Using Limon Sandbox Monnappa K A monnappa22@gmail.com A number of devices are running Linux due to its flexibility and open source nature. This has made Linux platform

Quick Start Guide Cerberus FTP is distributed in Canada through C&C Software. Visit us today at www.ccsoftware.ca! How to Setup a File Server with Cerberus FTP Server FTP and SSH SFTP are application protocols

Botnets: The Advanced Malware Threat in Kenya's Cyberspace AfricaHackon 28 th February 2014 Who we Are! Paula Musuva-Kigen Research Associate Director, Centre for Informatics Research and Innovation (CIRI)

Spyware US-CERT Summary This paper gives an overview of spyware and outlines some practices to defend against it. Spyware is becoming more widespread as online attackers and traditional criminals use it

From Georgia, with Love Win32/Georbot Is someone trying to spy on Georgians? At the beginning of the year, a curious piece of malware came to our attention. An analyst in our virus laboratory noticed that

Installation and Deployment Help Documentation This document was auto-created from web content and is subject to change at any time. Copyright (c) 2016 SmarterTools Inc. Installation and Deployment SmarterStats

What do a banking Trojan, Chrome and a government mail server have in common? Analysis of a piece of Brazilian malware Contents Introduction.................................2 Installation: Social engineering

Metalogix Replicator Quick Start Guide Publication Date: May 14, 2015 Copyright Metalogix International GmbH, 2002-2015. All Rights Reserved. This software is protected by copyright law and international

Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Presented 2009-05-29 by David Strauss Thinking Securely Security is a process, not

WildFire Reporting When malware is discovered on your network, it is important to take quick action to prevent spread of the malware to other systems. To ensure immediate alerts to malware discovered on

Astaro Security Gateway V8 Remote Access via SSL Configuring ASG and Client 1. Introduction This guide contains complementary information on the Administration Guide and the Online Help. If you are not

Sandy The Malicious Exploit Analysis. http://exploit-analysis.com/ Static Analysis and Dynamic exploit analysis About Me! I work as a Researcher for a Global Threat Research firm.! Spoke at the few security

ez Agent Administrator s Guide Copyright This document is protected by the United States copyright laws, and is proprietary to Zscaler Inc. Copying, reproducing, integrating, translating, modifying, enhancing,

orrelog Security Correlation Server Backup and Recovery Guide This guide provides information to assist administrators and operators with backing up the configuration and archive data of the CorreLog server,

INSIDE A BLACK HOLE By Gabor Szappanos, Principal Researcher, SophosLabs Introduction Without exception the most actively deployed exploit kit in the past year was the Blackhole exploit kit. [1]. Now that

GFI MailArchiver for Exchange 4 Manual By GFI Software http://www.gfi.com Email: info@gfi.com Information in this document is subject to change without notice. Companies, names, and data used in examples

Persist It Using and Abusing Microsoft s Fix It Patches Jon Erickson : isight Partners : jerickson@isightpartners.com Abstract: Microsoft has often used Fix it patches, which are a subset of Application

2X SecureRemoteDesktop Version 1.1 Website: www.2x.com Email: info@2x.com Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious

Best Practices Top 10: Keep your e-marketing safe from threats Months of work on a marketing campaign can go down the drain in a matter of minutes thanks to an unforeseen vulnerability on your campaign

Chapter 17 Transport-Level Security Web Security Considerations The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets The following characteristics

PHISH LOCKERS OUT IN THE WILD August 2013 RSA researchers have been increasingly witnessing the activity of highly targeted Trojans, dubbed Phish Lockers, used at the hands of cybercriminals to steal credentials.

The Epic Turla Operation: Information on Command and Control Server infrastructure v1.00 (August 7, 2014) Short Report by Laboratory of Cryptography and System Security (CrySyS Lab) http://www.crysys.hu/

intelligence at the edge of the network www.critical-links.com edgebox V4.5 Introduction: The Web Server panel allows the simple creation of multiple web sites using the Apache web server. Each website

Liaison Alert System # A-000049-MW The following information was obtained through investigation and is provided in conjunction with the s statutory requirement to conduct victim notification as outlined

IBM WebSphere Application Server Version 7.0 Centralized Installation Manager for IBM WebSphere Application Server Network Deployment Version 7.0 Note: Before using this information, be sure to read the

RFG Secure FTP Web Interface Step 1: Getting to the Secure FTP Web Interface: Open your preferred web browser and type the following address: http://ftp.raddon.com After you hit enter, you will be taken