2011-08-01
Abstract
As a follow-up to their article on the SpyEye malware infection framework, Aditya Sood and colleagues discuss the SpyEye bot and the tactics it uses for stealing information from victim machines.
Copyright © 2011 Virus Bulletin
This paper sheds light on the exploitation techniques that are used by SpyEye to spread infections. Last month, we presented details of the SpyEye malware infection framework [1]. In this article, we continue our research and will discuss the SpyEye bot and the tactics used for stealing information from victim machines.
The SpyEye bot [2] has to be installed on the victim machine to become a resident, and it is easiest to install code at ring 3. Conceptually, the OS is divided into four main rings starting from level 0 to level 3. The rings are used to define the access privileges within which code is allowed to execute. Ring 0 protects the kernel. Code that executes in ring 0 has very high privileges so malicious code running in ring 0 can be particularly virulent. In contrast, code executed in ring 3 is in the application layer, and has fewer privileges than ring 0. However, ring 3 rootkits can have significant capabilities. Ring 3 rootkits can use ‘CreateRemoteThread’, ‘VirtualAllocEx’ and ‘WriteProcessMemory’ to inject malicious code into running processes. It is also possible to enumerate and modify files, processes and registry keys. At ring 3 the rootkit can wait silently for keyboard strokes, and direct all the information to a centralized server using an HTTP communication interface. The SpyEye bot effectively runs as a user-mode (ring 3) rootkit as illustrated in Figure 1.
Rootkits are a class of stealthy malware which can be extremely difficult to detect because they sit between applications and the operating system. A rootkit running at ring 3 has the capability to hook application-level processes. The SpyEye bot will hook functions when a system call is initiated from an application. Rather than executing the normal operating system functions, malicious ones are hooked in. Hooking is efficient because dynamically linked libraries have predefined memory addresses and locations. This means that the locations of memory addresses are known and are not dynamically generated. The SpyEye bot hooks specific DLLs such as wininet.dll (Windows networking dynamic link library) to tamper with the HTTP data that flows between a victim’s browser and the target website. It also hooks the nspr4.dll routine, which is a core library used by the Firefox, Netscape and Flock browsers. The SpyEye bot uses Windows’ built-in Application Programming Interface (API) to execute hooking modules in the context of running applications. Since all browser communication occurs at a user-mode level it becomes easy for SpyEye to perform modifications by manipulating function calls. SpyEye basically performs two major operations on the DLL:
It completely removes and replaces the executable binary or DLL from the system.
It performs direct binary modifications in the memory address space.
The hooking procedure is illustrated in Figure 2.
The SpyEye bot monitors the types of applications running on a victim’s machine and infects processes using its maliciously designed plug-ins. As mentioned in [1], the SpyEye bot can be customized because it supports plug-ins that are specified within the SpyEye framework. The SpyEye bot can issue commands in real time to infect specific application processes. SpyEye can easily hide processes and even has the capability of escalating the privilege level of a process. In addition, it can hide the TCP/UDP port binding on a victim’s machine so that it becomes hard to detect the communication taking place between the bot and the backend collector. The SpyEye bot’s rootkit functionality has resulted in robust control over applications which, in turn, make it hard to detect.
In this section we will discuss specific tactics used by SpyEye to infect victim browsers and machines in order to spread. The tactics that we will discuss have been noticed in multiple versions and illustrate some stability in the SpyEye framework.
SpyEye’s recent versions starting from 1.2.x have shown a great improvement in designing customized plug-ins based on requirements. In order to support this, the SpyEye frameworks include a Software Development Kit (SDK) which has self-defined APIs based on the framework. The API calls bind a plug-in directly to the bot. There is no restriction on the number of plug-ins that can be used with the SpyEye bot. The design of customized plug-ins has actually diversified the infection pattern of SpyEye. Now it is possible for a single plug-in to communicate directly with the bot and send data back to the database. This design has resulted in modular infections. In order to use plug-ins with the backend collector, the SpyEye framework requires certain modifications to the database. In fact, for plug-ins the collector generates a new database every day. Malicious plug-ins can perform operations based on the attacker’s choice.
More technical details about specific plug-ins are discussed in the next section.
Web fakes are one of the most prominent tactics used by SpyEye to circumvent the normal functioning of the browser. Web fakes are fake authentication windows generated by the SpyEye bot when a user visits a specific bank website. For example, consider a victim who is visiting a Bank of America website and his system is infected with SpyEye bot. The bot generates fake windows or pop-ups masquerading as Bank of America to fool the user into entering authentication credentials. These are then sent to the backend collector. As the SpyEye bot resides in the system in a stealthy manner, it becomes easy to hook processes. Web fakes are also defined and configured in a raw format as text. The text is interpreted by the plug-in and then commands are issued to the bot to infect browser processes. The web fakes are generated as follows:
Web fakes have a direct interface with the SpyEye plug-ins. Once the bot is installed on the system, it hooks system DLLs as explained in the previous section.
As web fakes relate to HTTP communication, SpyEye hooks all the functions in Wininet.dll so that communication through the browser can be modified and monitored. This process works through DLL injection (a technique used to execute code in the memory space of another process by forcing the process to load the attacker-specific DLL). This technique is widely used by virus writers to keep track of the activities in the system and for performing modifications when required. Module hooking and DLL injection work collaboratively to take control of various processes.
The data is transferred to the processes by the same concept that is used by Windows OS, i.e. pipes. Plug-ins issue commands to the SpyEye bot which generates web fakes as described above and transfers data to backend servers via HTTP requests.
SpyEye uses a well-defined SDK for generating web fakes. The following functions are used:
DLLEXPORT bool IsGlobal(): This function is called by a plug-in itself at the start. It provides full access for the plug-in to communicate with all the infected processes so that it is possible for the plug-in to take control of all the infected interfaces directly from the source.
DLLEXPORT void Callback OnBeforeLoadPage(IN PCHAR szUrl, IN PCHAR szVerb, IN PCHAR szPostVars, OUT PCHAR * lpszContent, OUT PDWORD lpdwSize): This function is called by plug-ins to set a hook on the HTTP/HTTPS request so that the contents of the page can be reported back to the centralized repository for analysing the type of information going out of the network.
DLLEXPORT void Callback ProcessContentOfPage(IN PCHAR szUrl, IN PCHAR szVerb, IN PCHAR szPageContent, OUT PCHAR * szOut, IN OUT PDWORD lpdwSize): This function is used to infect the web page dynamically. It again performs a hook immediately before the page is about to render in the browser. It provides an edge to update page contents and injects additional web fakes into banking websites.
DLLEXPORT void FreeMem(LPVOID lpMem): This function is used to set the allocated resource free.
The list above provides a nice summary of how the SpyEye framework’s standard APIs can be used for malicious purposes. Figure 3 shows the list of functions that are used by the SpyEye malware infection framework.
The SpyEye framework has gone through a number of developmental changes since the first version was released. It has added a new anti-virus capability – an anti-virus module for third-party infection and self detection. This module actually enhances the SpyEye operations because the framework is capable of scanning the executables without any outside instruction. It looks quite strange for a malware framework to be using an anti-virus engine. Since the bot has the capability to send the data back to the collector module, it is also possible to scan the third-party executables when an HTTP URL is sent by a bot to the control panel. These features demonstrate the fact that malware is getting cleverer. The virus detection module is presented in Figure 4.
SpyEye has a built-in capability for supporting SOCKS connections. This feature was introduced in SpyEye version 1.2.x. When infection takes place in victim machines, it becomes hard to determine whether infected systems have leased IP addresses or systems that are behind NAT or firewalls. This feature helps in setting unanimous port connections through a SOCKS proxy for transfer of data between a victim machine and the control server. Basically, SOCKS is a network protocol supporting HTTP communication between client and server through the implementation of proxy servers to create a tunnel from a private network to the Internet. The SOCKS protocol is platform independent and can be implemented with ease, thereby supporting both Windows and *nix environments. This technique gets around firewall security protection because the HTTP traffic is relayed from different ports. The SOCKS proxy acts as a gateway. An IP authentication mechanism and identification protocol features are applied in the SpyEye framework so that the bot works appropriately. In addition, this protocol can be used to set up a stealth tunnel between a SpyEye bot and the centralized servers.
The SOCKS server is started on the same server as that on which the SpyEye framework is hosted. SpyEye uses the code shown in Figure 5 for configuring the SOCKS proxy on the server side.
The bot communicates with plug-ins and data is transferred directly to the SOCKS server, bypassing the NAT infrastructure. It works with insecure and secure connections such as HTTP and HTTPS respectively. Logging is also supported by the SOCKS server. Similarly, SpyEye supports an RDP and FTP back connect module. (Figure 6).
SpyEye is capable of injecting content into banking pages in real time as they are displayed. A number of techniques have been discussed in previous sections of this paper. The web injections [3] are more destructive in practice because they modify the content of the web page before the actual web page is rendered in the browser. The web injections occur on the client side. For example, a user with a SpyEye-infected machine visits a banking site. As soon as the website is about to load in the browser, the SpyEye bot injects custom content into the same web page. As a result, the content looks in line with the real web page, thereby implying the authenticity of the rendered content in the web browser. Internet Explorer and Firefox are injected in an extensible manner by SpyEye. Figure 7 shows the content injection.
SpyEye has an inbuilt key-logging mechanism that is perfectly designed for logging keystrokes from the victim machine. Basically, we have noticed form-grabbing activities by the SpyEye bot instead of complete keyboard hooking. In the form grabbing, all the content from HTML forms is stolen during the POST request and the bot sends that information back to the backend database. Form grabbing is one of the predominant features of SpyEye because all the user’s monetary transactions and login activities take place via form submission. In order to perform efficient form grabbing, the SpyEye bot hooks into the browser dynamic link libraries and hooks the data submission functions so that sensitive information can be stolen from the victim machine. In addition to this, SpyEye also uses a screen scrapping feature in which the bot takes snapshots of the victim machine as the user is inputting sensitive information and sends them to the backend server [4] in a compressed format. Figure 8 shows how the snapshots of the system are retrieved at the main panel.
SpyEye has an inbuilt plug-in that is primarily designed for stealing X.509 certificate information from victim machines. Basically, this is accomplished through Man-in-the-Browser (MitB) attacks. The SpyEye bot sits in between the browser and the destination domain, and since it has already hooked the HTTP communication interface, the bot is able to extract information from the certificates. This is done so that the bot can communicate with the legitimate domain without any hassles from the victim browser. Apart from this, stolen certificates can also be used to generate fake certificates for malicious purposes. Figure 9 shows an implementation of the plug-in that steals certificates from the Firefox communication interface.
SpyEye version 1.3.x has implemented the concept of distributed denial of service through inbuilt plug-ins. This functionality has been noted in the latest versions of the malware as a protection against anti-SpyEye detectors. Using this plug-in, the command and control server forces the installed bots to start sending packets against anti-detectors. Overall, the DDoS is achieved by harnessing the power of the victim machine through installed SpyEye bots.
Figure 10 shows how exactly the DDos.cfg plug-in is configured in SpyEye. This plug-in is not very effective at conducting denial of service attacks in a distributed manner, but the design could improve and become more robust in the future.
In this article, we have presented SpyEye’s most frequently used techniques. All the variants of SpyEye effectively use these tactics to exploit victim machines for malicious purposes.
The points discussed in this article demonstrate the advancements that have taken place in third-generation botnets.
[1] Sood, A.K.; Enbody, R.J.; Bansal, R. SpyEye malware infection framework. http://www.virusbtn.com/virusbulletin/archive/2011/07/vb201107-SpyEye.
[2] Sood, A.K.; Enbody, R.J. Hack In The Box – Spying on SpyEye. http://secniche.blogspot.com/2011/05/hackinthebox-ams-spying-on-spyeye.html.
[3] Malware at Stake (SpyEye & Zeus) Web Injects – Parameters. http://secniche.blogspot.com/2011/07/spyeye-zeus-web-injects-parameters-and.html.
[4] Malware at Stake, SpyEye Backend Collector. http://secniche.blogspot.com/2010/08/spyeye-backend-collector-generating.html.
