Setup and Analysis of ZeuS Banking Trojan V 2.0.8.9 w/ Volatility and LibVMI in a Virtualized Lab

Setup and Analysis of ZeuS Banking Trojan V 2.0.8.9 w/ Volatility and LibVMI in a Virtualized Lab by Philip Schwartz, with guidance from Dr. Irfan Ahmed University of New Orleans August 5, 2014

I. Introduction I began this project reading research papers and statistics on known botnets. Then moving onto how they work, which is limited to only what we have discovered so far. I did find that there has been research on infected Zeus (see Figure 1) memory images pertaining to version 1.x.x.x, however there was no apparent research done on much newer versions. Most research was done on RAM captures of infected machines and not on live machines. I happened to stumble upon a site with news about Zeus, which actually linked to one of the more recent known Zeus version. I then later stumbled upon the actual source code which was leaked. It was hosted on github, of all places (http://www.github.com/visgean/zeus). Figure 1: Background on Zeus Botnet This find really threw me off because of it's availability, after investigation this seemed almost as good as commercial software and relatively simple for someone with a basic background to crank this up and get it running. Whoever hosted it does state that this is for educational and analytic purposes only, but I mean come on. Is everyone a good guy? No, so I went cracking and investigating it, truthfully for educational purposes. I was able to find some help in actually installing this (for an older version), configuration, server setup, etc. And wow, did it seem surprising easy if you had the slightest clue on what you were doing and looking for. Even though I did have some trouble at some points in the setup it was for the most part easy if you had some technical background, database, and server experience. Most of my trouble came with the virtualized lab set-up and Linux based programs in Fedora. In this paper, I plan to walk you through the tools I used, my setup process, view the botnet functionality from both hacker and victim perspective, C&C commands, and my analysis of infected machine -- RAM captures with Volaility framework and through virtual machine introspection with LibVMI tools and programs.

II. Tools Used My host machine was running Linux, Fedora 20 (3.15.3-200.fc20.x86_64). 1. Volatility Forensics Framework (http://code.google.com/p/volatility/) - Open source collection of tools for memory forensics using volatile samples. 2. Xen Hypervisor (http://www.xenproject.org/developers/teams/hypervisor.html) - Hypervisor that runs on top of the virtual machines, allows Virtual Machine Introspection from host machine. 3. Convirture (http://www.convirture.com/solutions_xen.php) - Virtual Machine manager, which allows local hosting VMs with Xen. 4. LibVMI (https://code.google.com/p/vmitools/) - Virtual Machine Introspection Library, which allows the inspection of machine state and memory while running. 5. WinDBG - For debugging and investigating process structures in Windows. III. ZeuS C&C Setup I began setting up Zeus on Virt-Manager with QEMU, but had problems with installation of XP virtual machines. For testing I downloaded VirtualBox and was able to install XP with no problem, so I knew it was a QEMU or Virt-Manager issue. I eventually was able to set up the Botnet with victim VMs and play around with the functionality on VirtualBox before making a move to Convirture and Xen for VMI purposes. Here is the process I took in setting it up: -Install Convirture (v 1.0 if using Fedora, and Xen. Create a server on localhost with Xen Protocol. - I then installed 2-3 Windows XP virtual machines, 2 Windows 7 virtual machines (1 will be the C&C Server), and 1 Windows Vista virtual machine. I later installed 2 Clean Windows XP installs for comparison purposes (discussed later on).

- I then downloaded the Zeus Source from www.github.com/visgean/zeus onto my C&C VM. - Since this botnet requires a C&C server, with Database functionality and PHP, I downloaded WAMP (www.wampserver.com/en) onto my C&C VM. WAMP comes packaged with Apache, MySQL, and PHP. - The bot requires PHP, using the extensions mbstring, and mysql. So ensure they are enabled in the PHP menu. Also in Apache > http.conf, edit the Apache server config to listen on your specified port. I just left mine at 80. However, there are known other services that use this port, such as Skype for example, so to ensure that there are no conflicts you may want to choose another. - Ensure all services (SQL, PHP, Apache) are running. (The W in TaskBar should be green) - Once the server is setup and running, navigate to Zeus > Zeus-translation > output > server[php]. The control panel and installation for the server side is all written in PHP. Taking a look at the source will give you a hint at where the source code may have been produced.

Aside from that note, copy these folders and files: into the www directory, in the WAMP menu. - Now you would think you would just navigate to localhost/index.php, the default page in your browser. However you are greeted with a blank screen. Come to find out this is a safety feature for if someone were to stumble across your server IP, they would only see a blank index page and if they weren't sure it was Zeus would think nothing is hosted on this web server. So then you try localhost/cp.php and you would think you would have access to the control panel for the botmaster (or botherder, or hacker). However, you are greeted with this page: I'm fine? This happens because no installation (in the botmaster's server side) has been completed, therefore the CP isn't set up and won't allow you to even see a login. - Navigate to localhost/install/ and you should see the following page:

The first set of user and password is going to be the username and password you use to log into the control panel. Again, another feature for protecting unauthorized access to your botnets' control panel, incase someone were to stumble upon it. If you are using WAMP, the default user name and pass for SQL should be root with no password (i.e. blank). Here we also see we will need a database, so lets create one: - Navigate to localhost/phpmyadmin - Click on Databases Menu Option - And create a database, with your name of choice, with Collation option. - For simplicity I stuck with cpdb. -Now we head back to localhost/install to continue. You may also leave 127.0.0.1 or enter localhost. I would leave everything else alone, I did however use an encryption key. If you do this ensure that you copy+paste somewhere or remember this exactly as entered. I chose mnbvcxz for simplicity. You will need to remember this when building the bot executable. Now click: It may take a few moments... If all goes well you should see the following screen:

Note: I did have trouble at one point with root not having privileges to log in, or something along those lines, so I went into phpmyadmin and created a new user for database cpdb, and provided it with GRANT ALL PRIVILEGES, and that solved the problem. The installation creates all the necessary tables in the database for you! These help manage the bots in the control panel, such as name, scripts, and the reports that the bots send back to the botmaster. - Now just so I didn't have any problems with communication to my C&C server, I went into firewall settings. Start > Search for files and programs.. > Windows Firewall. Click on Windows Firewall > Advanced Settings > Inbound Rules > New Rule. Select Port and hit next type in the port field: Port # Specified In Apache, SQL Port (default is 3306). For example: 80, 3306 Hit next, next, and name the rule. Finish. I repeated the same steps for a new Outbound Rule on the same ports. - Now you should navigate to localhost/cp.php and you should now see the login screen instead: Log-in, and you should be taken to the main control panel and see the following page: You should be able to see the many features and information breakdowns that this control panel can provide, but at the moment we have no bots.

- Now that the server side of Zeus is set up it is time to configure and build the bot executable so we can see some sample activity in the control panel. IV. ZeuS Bot Builder Now that we have set up the server side, navigate to your Zeus folder again, and go to Zeus > Zeus-translation > output > builder. You should see two config files, one webinjects file, and a zsb.exe file. Double click the zsb file and you should see: - Now click Browse.. and find the config.txt file, and click open. - Next click Edit... and you should see: - Now you must edit the url_config, url_loader, url_server, and the AdvancedConfigs sections to point to your server IP address. For this part it cannot be localhost, you must actually find the IP address of your C&C server and port. You can do this easily in Windows by opening the command

prompt (cmd.exe) and typing ipconfig. It should list your IPv4 address. Enter that address in each of those sections followed by :Port# (if it is not the default Port # 80) and leave the extensions (i.e. /gate.php). - Very Important! Do not forget to edit the encryption_key entry to whatever key you specified during installation or else your infected bots will not be able to communicate with your server and database. - Once completed, save the config.txt file and in the ZeuS Builder click build configuration. When prompted to save, save the config file as config (which it should already prompt you to do). It should finish with: BUILD SUCCEEDED! - Now click the build executable button and save it as bot (which it should already prompt you to do). This will be the infectious file that will infect your lab victim VMs. It should also finish with: BUILD SUCCEEDED! Now you have built the executable. - Now you must copy cfg1.bin, config.bin, webinjects.txt, and bot.exe to the www directory in the WAMP tool for hosting. - For testing purposes, I suppose, the builder contains an information tab where you can check to see if your machine is infected. So to test that the bot was configured correctly, open your browser and go to localhost/bot.exe, download and run the bot. Now go back to the ZeuS Builder and in the information tab enter in the encryption key that you used and hit refresh. The information on the bot you just executed should appear, with version number, and the running process of the bot (which is randomly generated). -Also check localhost/cp.php to see that you have 1 new bot! Yourself! You can also safely remove the bot once you see that it clearly works, and restart for complete removal. -Now you are ready to infect your test machines easily. Within each VM that you want to infect open up explorer and type in the IP address in the address bar and download the executable. For example: 127.0.0.1/bot.exe Run the bot and allow. You may notice but if you look in your downloads folder the executable is gone after you have downloaded it. It deletes itself after execution! Pretty slick, especially if it was disguised and not clearly named bot.exe you may not be as suspicious.

V. ZeuS Control Panel and Functionality The ZeuS control panel offers the botmaster a pretty clean interface to handle many bots and receive detailed reports on each bots activity. In my setup I've currently infected 6 virtual machines. I will show you some snap shots of what the interface can provide. From running for a couple weeks, the 6 bots have generated 13 thousand reports in the database. The amount of reports can be edited in the configuration file for the executable. But how can you change the configuration on already infected bots? The CP, control panel, allows the botmaster to generate scripts with pre-defined commands, including bot_update. The bot knows from configuration where to find the new config file, so long as it is where we specified in the previous configuration file (i.e. the server IP we specified). This also allows the botmaster to update version numbers as ZeuS updates were coming out. The bot we are inspecting was most likely about to become version 2.1.0. This allows the botmaster to not have to go through the trouble of infecting victims all over again. Back to the 13,000 files, the CP has a search function to string search the entire database. Say the hacker is looking for passwords. The hacker can just search for string Facebook throughout the entire database and receive a detailed report pertaining to Facebook. Although hackers would most likely be looking for banking information, here is a Facebook search for example :

The report shows which bot the report was generated from, the date, the submitted data, process name, and as you can see much more. The bot captures and intercepts POST data, so that all submit input fields are captured and generated in a report. On the infected side, the site acts normally and the user should have no suspicions that it is in fact infected. Only until they realize their account has been compromised. Another intelligent, in the eyes of the hacker, maneuver the bot does is that it deletes all known browser cookies on install. This requires that all newly infected users must re-login to all of their social, banking, and shopping accounts. And now that ZeuS is installed and able to capture all new input data, all the re-entered passwords now will be seen by the botmaster. For example, imagine a botmaster has 10,000 plus bots, it may take him days, weeks, or months to get around to compromising accounts. So for instance he finally gets around to testing a password for WellsFargo from 6 months ago. However, the password does not work and the user now may have selected an option like Keep me loggin in. The CP also has a build in script command to delete all cookies on the specified bot(s). Problem solved, now they will have to re-log-in again. Here is a list of the many other pre-defined script commands:

I went through and tested a lot of these commands, and didn't have much trouble getting them to work. Almost all of them executed on user log-in. From analysis this becomes evident (injections into winlogon.exe), which will be dicussed later. The last command I was investigating was the Kill OS, that has been infamously heard of. If you haven't heard of it, it basically destroys the entire operating system making the computer unbootable. A few years ago there was a headline pertaining to ZeuS and the KOS command: Src: http://arstechnica.com/security/2009/05/zeus-botnet-hits-the-kill-switch-takes-down-100000-pcs/ So I decided to try all kinds of different variations of a type of kill OS command such as: kill_os os_kill os_destroy destroy_os to no avail. I ended up using user_destroy, which actually worked. It doesn't kill the entire operating system but it destroys the user account. After the user logs off, and tries to log back in. The entire user directory is deleted and the only thing remaining is the icon on the Windows log-in screen: When attempting to click the icon to log-in the user is greeted with the welcome loading screen for about 2 seconds and immediately logged off and returned to the Windows login screen. This action could slow the victim in noticing bank transfers, account compromises, etc. Noticeably benefiting the attacker, and leaving the victim unknowing for some time. Another very interesting feature of the CP is the screen capture & information ability of the bot. It can directly send still in-screen captures of the bot.

If the hacker wanted to it could keep a very close eye on you by having the stills constantly refresh to have an almost live stream of the actions being taken on a victims computer. The CP also has the ability to save the screen shots. So if for instance a victim has a confidential file open, the hacker can save the still for later exploitation. The bot also performs specified html injections that are spelled out in the webinjects.txt file that was used during configuration of the executable. These are editable and can have entries added to them per the hacker's needs. An example of an injection would be: Note: This isn't an actual live webpage, this is an example to show before and after a Zeus web injection. On the left is the webpage before the webinject, and on the right you can see the injected Pin input field. An unsuspecting or oblivious user may enter their pin in the input field. These injections are mostly used for personal information such as social security numbers, pin numbers, passport numbers, ID numbers, etc. On submit all these input values are captured by the bot and detailed in reports.

Another alarming feature of CP is the script command bot_bc_add which can allow you to add a socket TCP port on the specified bot and have it open. This can allow the botmaster to remotely connect through the opened socket port through VNC or Telnet. For example I sent this script to one of my infected VMs: From the control panel you can also check to make sure the socket was successfuly opened by checking it: Now from my C&C VM, I can connect to the infected computer through telnet or VNC and observe that the connection to that port can be established by using netstat: From the C&C point of view: And you can also check this from the bot's perspective (which most victims wouldn't): Once established the hacker can execute commands, and also if need be use the CP to send a script command to download the necessary software for VNC connection and carry out all kinds of destruction. There is still a lot to learn about maximizing the entire functionality of the control panel and it's actions. I was able to touch on the ones that I found very interesting, but I'm sure there are some other interesting and alarming functionalities that I was unable to learn, test and carry out. VI. Analysis with Volatility 2.3.1 For analysis in Volatility I had to dump the memory of one of my infected virtual machines. I actually used a built in dump-memory program included in the LibVMI example library to achieve this. If using Xen and Convirt: cd../libvmi/examples/ make sudo./dump-memory VMName Output.dd

I was able to obtain a raw image file to use with Volatility. Now onto profiling, cd (change directory) into your volatility folder. Since I already knew which OS and Service Pack I had installed for the infected machine I didn't need to figure out the profile. If you are looking at a dd file in which you don't know the OS or profile, you will need to run: python vol.py -f XPb.dd imageinfo Note: XPb.dd is the name of my image file I'm looking at, replace it with your image file name. Next I ran process list (pslist), to get a list of running processes on the machine. Nothing looks too suspicious, all seem to be Windows known processes. Now I checked to see if any processes are hiding using psxview. Nothing immediately throws a red flag, I do note here that irru.exe is showing False in the thrdproc and no other process is. However it is not hiding from the pslist or psscan plugins, which detect all running processes.

I then took a look at Task Manager, just to compare output of pslist. The process irru.exe is hiding itself and is not visible to the user from task manager. This is very interesting since the process would go undetected to most victims unless they were able to dig deeper. Next I checked for an open connections, which there should be. (To our C&C) However there are no open connections at the time of the memory dump. I now will check for previously opened connections. I end up finding that explorer.exe is making a remote connection to 192.168.100.176:80. This is the connection to the C&C server hosted on the hacker VM. I then ran pstree to see if any other processes were child processes of explorer.exe, which could be causing this remote connection. Sure enough irru.exe is a child process of explorer.exe. This must be the executable the bot created on installation.

Running the command malfind spits out a ton of information on injected code into running processes on the machine, meaning the installation must have injected itself many times into different Windows processes. For now I'm only interested in explorer.exe, PID = 1348. Here I found where the aparent irru.exe process is injected into explorer.exe. MZ is a file header for an executable (.exe) file. This is where irru.exe is being deployed at address 0x1330000. I also wanted to check winlogon.exe because from testing I noticed all scripts sent from C&C to bot are executed on user login. Sure enough there is a ton of code injected into winlogon.exe. Although I was not able to fully understand what the assembly is doing at those addresses, I'm assuming it is adding to the register address of EAX (moving it's address location) and using function calls elsewhere that use EAX to carry out the bot's needed instructions because 95% of the injected code is calling: ADD [EAX], AL Now onto looking for API hooks I was able to see plenty of hooks aimed at WININET.dll and USER_32.dll, the bot seems to be hooking into plenty socket communication and internet request functions to intercept victim data.

ImpScan was used to see a list of imported functions on irru.exe but returned nothing because the DLLs could not be read. So instead I used it on explorer.exe and found plenty of imports, a lot of them most likely harmless and the output was very verbose. So I moved on to looking for handles that irru may have had open. Irru has open handles in explorer.exe,wscntfy.exe, and wuauclt.exe which is also where plenty of APIHooks occur. In the end it is clear to see that something is definitely fishy from analysis with volatility. Even though I knew it was infected with the ZeuS bot, it is pretty clear that irru.exe is a malicious process that is carrying out network communication to a remote address.

VII. Detection of ZeuS with LibVMI Tools Since we now have an idea of ZeuS' allocation and process injection, for the remainder of this project the idea was to detect ZeuS or abnormalities within processes and their heap allocation. To do this I used a library called LibVMI which allows virtual machine introspection through a Xen hypervisor. Src: https://code.google.com/p/vmitools/ The idea was to compare EPROCESS structures of the known injected processes that ZeuS uses, i.e. explorer.exe. To do this I was given sample code from Dr. Irfan which checked modules between two VMs. I was able to take this program, written in C, and modify it to check the structure of Windows' processes. To better understand EPROCESS structures I used WinDBG (Windows Debugger) on both an infected and a clean VM. I used it in kernel debugging mode to debug local processes.

-Set the system symbol path with: -Run.restart /f and reopen the command window. -Enter!process 0 0 to get the list of current processes running and their addresses. -Now we can examine the actual EPROCESS structure since we have the address (for example explorer): This output shows the different data structures and attributes of the EPROCESS structure and their offsets for access and retrieval. For instance here we can see that this is the correct address for explorer.exe and we can also see the Peb structure and further examine that in the debugger by using it's offset 0x1b0. This will return plenty of attributes and their offsets pertaining to the peb data structure. I also used this to examine the ProcessHeap structure within the peb and others. Using all of this information on the EPROCESS structure, I was able to modify the modulechecker to check processes between two VMs. The program goes through the structure using the given offsets from the debugger and locates many of the attributes, on each live VM, of the EPROCESS structure and outputs them. Then the program grabs DOS Header, DOS Stub, NT Header, File Header, Optional Header, and all of the Section Headers. Once the information is collected from both VMs the MD5 of the data is calculated and compared to each other along with the CRC. If there is a match it is outputed and the contents of the EPROCESS structure are identical. If it is not a match then the program outputs that a match was not found which means that the contents of the two processes are not identical. The output of the program is very verbose, so for this purpose I will only show the relevant parts of comparing explorer.exe between a clean XP install and an infected XP bot:

Here I found that the.text section headers do not match between the two processes. The.text section is where code in run within assembly language. For this reason we can understand that this is true and coincides with our findings of code injection into process explorer.exe with Volatility. The bot injects it's code into the.text section of process explorer so that it's code will be run with the process. To ensure that I wasn't discovering false positives I compared 2 XP clean installs with the same process and the.text section of explorer matched. I then went on to compare the two bot processes on two infected XP machines (processes irru.exe and ehzad.exe), so I altered to the program to accept two different process names. Originally it

would only take one process argument. And sure enough. Everything matched between the two. Since the output is so verbose I did not provie a screenshot of the output. In conclusion I found that it was possible to compare the internal structure of processes to locate differences between the two and possibly locate malicious abnormalities between and clean and an infected process. VIII. Process Heap Allocation The next idea was to also use LibVMI to detect and observe process heap allocation. The idea was to compare two of the same processes heap allocation to detect malicious activities within a process space. Since most process actions require memory space to complete them, processes are constantly allocating heaps of different sizes. To start off, I went back into WinDBG to take a look at the Process Heap structure within the peb data structure of a process. Using the offsets provided it is pretty straightforward on how to examine the structures: Which gives us the output of the peb structure, where we can see that the ProcessHeap is located at +0x018. Now we can access the heap structure with: Which gives us a ton of information on the heap structure at that address.

Using this I was able to observe some code Dr. Irfan had written in C with LibVMI, which looked for heap sprays, and modify it to retrieve the characteristics and attributes of each allocated heap within the process. Although I have not completed this area of research the goal is to finish adding to this code, and enable it to compare each heap of an infected explorer process to that of a clean explorer process to search for any differences and/or malicious allocation. IX. Conclusion In the end I believe LibVMI provides a great way to look at live VM memory and structures without having to take a still memory dump and analyze them as I did with Volatility. LibVMI can allow the altering of the live VM while maintaining access to the contents of the VM through the LibVMI library. Overall, I believe I have learned plenty about ZeuS. Understanding the configuration and setup of the botnet taught me a lot about network communication and the different tools that ZeuS uses at expense to the victim. It was really amazing, the functionality the bot included and how commericial like the software is. I can only imagine how easy the new variants are being made so that the malware writers to can maximize their profits. In the end I wish I would have been able to get my hands on a more recent botnet. I also learned plenty about Linux, through trouble shooting, package dependency problems, and plenty of other head-scratching/googling I had to do. I also learned plenty about Virtual Machine

management tools including virt-manager, convirture, QEMU, Xen hypervisor, and VirtualBox. I also feel as though I learned plenty about Windows process internals and the different structures within the processes. Since I hadn't had much experience with processes and OS internals (I've only taken one forensics class thus far) it took some time to understand. Although I know I don't know everything about the OS and the internals of processes, modules, heaps, etc. I learned plenty from this project and feel much better versed. Throughout the process I went through plenty of problems with package dependencies. Some programs worked fine on Fedora while some did not. I had a weird bug with Convirture: This wouldn't allow me to provision any VMs. I ended up having to roll back a version to make it work. Before this I was trying virt-manager and couldn't even install XP which was frustrating, because I had no problem in VirtualBox: There were plenty of other problems I had that were not documented, but in the end I feel I was able to put together an in-depth paper and report on my findings, setup, functionality, and analysis of the ZeuS Botnet. X. Recent News of Variant GameOver ZeuS While researching and experimenting with Zeus there were recent headlines of a variant called GameOver Zeus, which was said to be taken down by the FBI.

Src: http://www.zdnet.com/gameover-zeus-botnet-seized-two-week-window-to-protect-yourself-sayauthorities-7000030110/ This is alarming since now the botnets are getting much more sophisticated, some not even requiring users to accidentically click something. Now some are using P2P (Peer-to-peer) algorithms to infect computers that are communicating with each other for example on the same network. Many believe these variants, no matter what they are called, are all spin-offs or variants of the first ZeuS botnets. Also I would speculate having the source code hosted on github, the one we are investigating, isn't helping slow down smarter and stronger variants of this malware. The problem comes when trying to keep up with protecting susceptible users is nearly impossible. By the time white-hat hackers have a chance to investigate infections, the malware writers are already developing a stronger piece of malware. However, even if does seem like a losing cause we must push forward to learn, experiment, and develop techniques for detecting and observing malware in the wild. For this reason, I really did enjoy this experiment. I've learned a whole lot about forensics in general, as prior to this I had only taken one computer forensics class. Using new tools (windbg, Volatility, and LibVMI), an unfamiliar OS (Fedora Linux), and discovering new things has made this a wonderful learning experience.

XI. Citations [1] http://www.wiki-security.com/wiki/parasite/zeustrojan/ [2] https://code.google.com/p/volatility/w/list [3] http://www.zdnet.com/gameover-zeus-botnet-seized-two-week-window-to-protect-yourself-sayauthorities-7000030110/ [4] http://arstechnica.com/security/2009/05/zeus-botnet-hits-the-kill-switch-takes-down-100000-pcs/