2011-07-01
Abstract
The SpyEye bot has a sophisticated, modular design and has improved its capabilities over time. In this article, Aditya Sood and colleagues examine SpyEye’s modules and map out how they are initialized and how they interact with each other, providing an insight into the design and methods of the bot, and into an effective instance of modern malware.
Copyright © 2011 Virus Bulletin
Recently, the SpyEye bot has been infecting machines across the Internet, and since it targets online banking it has the potential for significant damage. We have dissected and analysed multiple generations of the SpyEye bot to learn how it infects systems, how it hides its presence, and how it gathers information. SpyEye has a sophisticated, modular design and has improved its capabilities over time. It behaves like a Ring 3, application-layer rootkit in that it applies hooks into applications to run its modules instead of Windows code. We examine SpyEye’s modules and map out how they are initialized and how they interact with each other. We have observed the bot in action and tracked changes in the registry and other files. The details provide an insight into the design and methods of the bot, and into an effective instance of modern malware.
When asked why he robbed banks, notorious bank robber Willie Sutton famously answered: ‘That’s where the money is!’. Today’s online criminals follow the same reasoning, but with a twist: rather than targeting the banks themselves, they attack the banks’ customers as they carry out transactions online. Widely deployed sophisticated bots reside on victim machines and become activated when a target (banking) website is loaded in a browser. The SpyEye bot is an example of such a piece of malware [1], [2].
A significant amount of research is being conducted to understand the design and exploitation tactics used by banking malware to corrupt access to financial websites and bank domains. Our analysis of SpyEye is based on the fact that it is essential to understand the design of the various components that are put together to build a composite framework for spreading the malware – it is difficult to design a solution if the malware framework is not sufficiently well understood.
Bots [3] are used extensively as part of malicious frameworks to infect victims’ machines and turn control of the machines over to the attacker(s) via a central server. In general, bots are stealthy programs that run as hidden processes in the context of the system. Once installed, a bot takes control of the victim’s machine and uses network connections to transfer data to the controller domain. When a number of bots are interfaced to a single control server, they form a botnet – a network of bots. Traditionally, botnets have harnessed the collective power of the infected machines to attack dedicated targets for exploitation and to take down networks via distributed denial of service attacks. Recently, some bots have been designed for the purpose of individual operations rather than joining forces for combined attacks, meaning that attackers have an increased ability to harvest data – in particular users’ banking information.
Most bots exploit users’ lack of security awareness. Users are often unaware of malware operations taking place on their machines. Many users believe that the firewalls and anti-virus software that they use will protect them from all malware. Users are often unable to differentiate between legitimate and illegitimate websites. Users often have little or no idea of the capabilities of web malware to exploit their system. Finally, users often harbour misconceptions about the ability of limited access accounts to protect them from malware [4]. Collectively, all these factors play a critical role in the successful execution of web malware and system exploitation.
A bot is an executable that installs itself on the victim machine and performs stealthy functions by manipulating API calls. Sophisticated malware has built-in anti-protection features designed to thwart fraud detection systems which are triggered by unusual transactions. For example, a stealth banking bot is capable of rewriting bank statements using a user’s credentials. We have found in SpyEye a keystroke logger that captures the user’s bank credentials and transfers them to the control server. The keystroke logger [5] remains dormant until the target (banking) website is loaded into the browser. Some bots also take screenshots of the user’s activities on banking sites to circumvent anti-keylogging protection.
Many web malware frameworks exploit browser flaws to install bots via drive-by downloads. In general, drive-by-download attacks infect a system with a dropper file. The dropper is a compressed executable which, when activated in the system, extracts to create a bot. Droppers are used to bypass anti-virus checks and thus to help successfully load the bot onto the victim machine. Early versions of SpyEye employed a generic dropper, but newer versions use customized exploits. Another advanced characteristic we see in SpyEye is a new model of exploitation and native SDK used for designing malicious plug-ins – factors that make SpyEye a bit different from other exploitation frameworks. One bot framework that is similar to SpyEye is the Zeus framework [6], [7], which also targets online banking – SpyEye has added a detection module [8], [9] for killing the Zeus bot if it is found on the infected system.
During the course of this analysis, various versions of SpyEye have been analysed to mark the developmental changes taking place.
SpyEye is designed in a modular fashion with a number of components that work together collectively. The modular design allows for the enhancement of specific capabilities in real time. The dynamism of this design plays a key role in the bot’s success and its ability to collect information from infected machines. The goal for SpyEye is a mass infection of the web. Such a widespread infection is possible only if the design of the malware framework is good enough and dynamic enough to bypass generic security protections. The SpyEye dropper file includes various configuration parameters such as a path to the control domain as well as to the main admin and form grabber control panels (described later). When the dropper executes on the victim system, it generates an encrypted config.bin file as well as the SpyEye bot itself, which is named ‘cleansweep.exe’ by default. However, SpyEye stopped using the dropper after version 1.0.75. Nowadays, a builder generates the bot directly with customized names utilizing modular controls in the builder.
A generic model of SpyEye is shown in Figure 1. The design of SpyEye constitutes four major components which are described in the following sections.
The builder is the main component of the SpyEye framework. It is used to generate a bot based on the specific build settings defined in a configuration file. The builder component uses configuration file entries to execute various modules and functions for assembling the malicious code. When this code is compiled, an executable is generated. This is a self-sustainable executable with the capability to perform stealth functions and network operations. The entries in the configuration file specify paths to local and remote resources which are used to include modules dynamically. The configuration file resides in the main admin panel and it is included during the build process.
The SpyEye builder is protected with a collaborative protection mechanism using VMProtect [10] and Hardware Identifier (HWID) [11]. VMProtect is used for obfuscation whereby machine instructions are changed into pseudocode. The generated binary has a small VM instruction interpreter which converts the pseudocode to machine instructions on execution. The pseudocode generated by VMProtect is always randomized and there is no standard output, thus making it time-consuming and hard to analyse. VMProtect can be reverse engineered by converting pseudocode instructions to assembly instructions, but this is a labour-intensive process. HWID is used in SpyEye to provide licences to single machines so that the builder cannot be installed on a different machine. Licensing also complicates analysis.
Thanks to the protection mechanisms it took significant effort to pull the code apart for analysis. Both the VMProtect and HWID mechanisms had to be reverse engineered and then applied. Furthermore, if the parameters were not applied carefully with respect to our analysis code, the system would detect a difference and the malware’s inbuilt protection mechanism could shut it down. It is possible that the building of the SpyEye bot may not occur at the primary control server. Some of the components of the SpyEye framework are decentralized across the web. The installation and configuration files are usually present on the main botnet servers. As the configuration file is included from the remote server, an appropriate encryption key is used to maintain the integrity of the file. Because of the built-in integrity check, tampering with the configuration parameters as part of the analysis process sometimes results in the shutdown of the SpyEye framework. The builder uses a connection interval property to avoid delays while the configuration file is in transfer mode. The generated SpyEye bot can be packed with UPX in order to reduce its size. This compression both helps in the rapid downloading of bots to victim machines and adds an additional step to the reverse engineering process.
SpyEye infects browsers and exploits their inherent functionality in order to steal information. Some bots can remove cookies from the victim machine – the builder has a self-initiated module of cookie cleaning that can be included during compilation. Plug-in capabilities and web injects can be rendered into the bot during the build process. SpyEye uses a ‘SPYNET’ mutex that allows it to run in a multi-threaded environment. It creates the mutex with a unique name during the build process.
The second component consists of the admin panel. This controls the structural dependencies and administrative operations of the SpyEye bot. It is the information hub that is central for performing various functions in the building of the bot. The admin panel provides updates to the SpyEye builder for configuration and building an executable. It keeps track of the various changes that are taking place in the building process and updates it with further information. In addition, the admin panel is responsible for controlling the nature of the plug-ins that are used by the SpyEye bot for infecting machines. The admin panel uses three metrics for defining the plug-in control. These metrics include plug-ins used, plug-in count and global identifiers for performing actions. Global actions are defined based on the infection statistics from various countries. These global actions provide wide control over the operations of bots by distinguishing them geographically around the world. The admin panel also provides a description of third-party infection by loading an executable from the primary bot. This is a part of chain infection in which one bot interacts with another through the admin panel.
The main admin panel generates a statistical output of various infections in the form of graphs segregated into various metrics such as number of infections, countries infected, etc. The admin panel is the main controller of the stolen information in all versions of SpyEye. In newer versions, the database is separated from the admin panel to reduce complexity in order to increase the performance of individual components in the framework. A new credit card manipulation module has been added in order to change users’ critical information. This module performs modifications in the credit card information stored on banking websites. Successful operations result in a change in information (such as credit card pin number) without the user’s knowledge. Another module is designed to generate and delete billing entries in the compromised user account. This type of infection aims to remove all traces of illegal operations in the user account. Newer versions have DDoS and web inject plug-ins that work on all types of browsers.
A primary goal of SpyEye is to steal banking information from victims’ browsers in order to perform fraudulent activities later. The form grabber is designed to grab user account credentials from web forms used for banking transactions. Primarily, this form grabber is the basis for keylogging activities on infected victim machines.
The keystrokes can be captured in two ways. First, the keylogger (a.k.a. form grabber) grabs all the keystrokes and dumps them into a log file. Second, the bot has a built-in capability to take screenshots of every keystroke on the victim machine. Screenshots are useful for working around anti-keylogging defences. The bot is activated when a bank’s website is loaded into the victim’s browser. The bot takes screenshots of keyboard activities and sends them back to the admin panel as shown in Figure 2.
The form grabber admin panel tracks all the developments made by the SpyEye bot installed in the victim machine. The stolen credentials are displayed in the form grabber admin panel on a daily basis. SpyEye version 1.2.x has a different set of PHP files used for stealing credentials and managing log data. Every form has a specific module associated with it. For example: frm_cards_edit.php has a module mod_cards_edit.php which is designed as shown in Figure 3.
The form grabber admin panel has the following modules incorporated in its design:
The info module provides all the HTTP header and response communication information with appropriate parameters. For example, a victim opens a banking website and starts to perform a transaction. The resident SpyEye bot hooks that communication interface and sends the information back to the form grabber admin panel. All the POST and GET requests are appropriately hooked to steal information.
The statistical module in the form grabber admin panel provides information about the infected websites that a particular host visits. It is used to keep track of the history of the victim machine.
The form grabber admin panel has built-in functionality for capturing screenshots from victim machines at the time of infection. This advanced functionality subverts anti-keylogging defences.
SpyEye is well known for stealing Bank of America (BOA) accounts. Our analysis has shown that SpyEye has a built-in BOA grabber module which is very effective at stealing BOA credentials from the victim browser when a website is active (see Figure 4). Apart from this, SpyEye also has FTP and POP3 account grabber modules.
The backend collector is a database component of the SpyEye framework. In general, the collector is a daemon that runs independently of the admin panel. This database has no dependency on the logs circulated and stored in the main admin panel. SpyEye provides an option for using the collector database independently. All the bots present in the bot network send data in the form of log files, including screenshot data, directly to the SpyEye collector. It is implemented with PHP and a MySQL database for flexibility and reliability.
The backend collector uses the LZO data compression library [12], which has extremely fast compression and decompression capabilities, to enhance the optimization of traffic. LZO is a real-time applied compression library which is platform independent. The speed helps ensure that in practice there is no procedural delay in accepting a log from a SpyEye bot. SpyEye provides relative functions as a part of its API as void TakeGateToCollector(LPVOID lpGateFunc) – the code is presented in Figure 5.
The backend collector code illustrates the simple functioning of data collection using plug-ins, and it shows the way data is collected and transferred back to the backend collector.
In this paper, we have presented a comprehensive design model of the SpyEye bot infection framework. Our analysis of the SpyEye bot infection framework has provided us with a unique opportunity to understand the exploitation techniques used by SpyEye in executing the attacks for stealing critical information from victim machines. Design level understanding helps us to modify our analytical methods which enable us to dissect malware more efficiently. We will be detailing our techniques and the tactics of the SpyEye botnet in a follow-up article next month.
[1] Symantec Security Labs Report (2010). Trojan.Spyeye. http://www.symantec.com/security_response/writeup.jsp?docid=2010-020216-0135-99.
[2] McAfee Avert Labs (2007). Trojans – A Reality Check. http://download.nai.com/products/mcafee-avert/blog/dc-15-dirro_and_kollberg.pdf.
[4] Dagon, D.; Gu, G.; Lee, C.; Lee, W. A Taxonomy of Botnet Structures. Annual Computer Security Applications Conference (ACSAC), 2007.
[5] Limited Account. http://www.prevx.com/blog/83/Is-Limited-User-Account-enough-Not-really.html.
[6] Holz, T.; Engelberth, M.; Freiling, F. Learning More About the Underground Economy: A Case Study of Keyloggers and Dropzones. Reihe Informatik TR-2008-006, University of Mannheim, 2008.
[7] Zeus Tracker. Zeus Tracker Monitor. https://zeustracker.abuse.ch/monitor.php.
[8] Admin. ZeuS Tracker Online Again With New Features. 19 September 2010. http://www.abuse.ch/?p=2722.
[9] Coogans, P. Spyeye Bot versus Zeus Bot. February 2010. http://www.symantec.com/connect/fr/blogs/spyeye-bot-versus-zeus-bot.
[10] Basics, D. SpyEye versus Zeus - Trojan War. 14 March 2010. http://sites.google.com/site/delphibasics/home/delphibasicsarticles/spyeyeversuszeus-trojanwar.
[11] Rolles, R. http://www.usenix.org/event/woot09/tech/full_papers/rolles.pdf. Usenix Woot, 2009.
[12] HWID. http://www.webopedia.com/TERM/H/HWID.html.
