This series of articles will present an analysis of a rootkit named ZeroAccess. This malware, also known as Max++, is a devious piece of code that works on a kernel level to bypasses virus scanners and continues to evolve in each new release discovered in the wild. Throughout this series I will explore the INT 2D instruction, an anti-debugging technique that is employed by this malware. The INT 2D instruction causes a byte scission and is utilized by ZeroAccess to prevent accurate analysis of the malware and ultimately used to increase the lifespan of the program. Furthermore I will present experiments and results that show the dynamic behavior of the INT 2D instruction and what factors, including the debugging environment, will change execution. In the following articles I will also continue to reverse engineer the ZeroAccess malware and analyze how it manages to infect a computer driver, modify the export table, encode its own export table, create a hidden partition, and ultimately remain hidden while it takes control of a computer belonging to an unaware individual.
1. Background Information
Malware stands for the term malicious software. Viruses, trojans, spyware and rootkits are all examples of malware. They are undesired and deceptive programs that are installed onto a victim’s computer without their consent. The goal of these programs is to exploit a computer for various reasons. One reason that hackers write and release malware is for reputation or personal curiosity. Currently, a more common motive is that malware is written by hackers for profit and financial gain. One example of this type of malware is the root kit named ZeroAccess.
ZeroAccess was first seen by VirusTotal on January 24, 2010. It is a very advanced rootkit that uses kernel calls and targets windows based machines. ZeroAccess utilizes undocumented system features and employs sophisticated anti-forensic techniques to avoid analysis and increase its lifespan. When a system is infected with ZeroAccess, the windows system files are modified and kernel hooks are created. After the hooks are in place, the program is now able to hide its processes and network connections. It also has the ability to avoid detection and removal by antivirus scanners. If a virus software attempts to access its files or processes, ZeroAccess immediately kills that service and disables the virus software.
2. Network Behavior
Let us first analyze a system that is infected with the Max++ rootkit and check the network traffic of the compromised system. In order to safely run an instance of the malware, I set up a virtual environment with virtual box. I used two virtual systems, first a machine with the Windows XP Service Pack 2 operating system, and second a system running Ubuntu. I expected the Max++ malware to hide its communications in the Windows XP system so I routed all the network traffic from the Windows system to run through the Ubuntu system. In the Ubuntu system I utilized a packet sniffer called Wireshark to inspect all incoming and outgoing packets. My goal was to find any request that Max++ makes to contact a remote server. For the Windows machine I configured the system to use an internal network card in virtual box. Figure 1.1 displays my configuration for the windows guest machine.
 |
| Figure 1.1 - Network configuration for the Windows XP virtual system |
Also I enabled hardware virtualization because Max++ makes use of hardware breakpoints. Figure 1.2 is the system configuration for my system.
 |
| Figure 1.2 - System configuration for the Windows XP virtual system |
Second I configured the Ubuntu machine to use the internal network card and accept connections from the windows guest machine. Below are my settings for the Ubuntu machine.
 |
| Figure 1.3 - Network configuration for adapter #1 in the Ubuntu virtual system |
I also enabled the second network adapter in the Ubuntu system. This allows me access to the host internet connection. Below in Figure 1.3 is my network setting for my Ubuntu machine.
 |
| Figure 1.4 - Network configuration for adapter #2 in the Ubuntu virtual system |
In order to complete the setup of the two virtual systems I also had to set up the IP forwarding and find out the DNS server to gain internet connectivity. After I had the systems set up I was able to use Wireshark in the Ubuntu machine and monitor all network traffic from the windows system. An important note to make here is to always make a snapshot of the virtual system before the malware is run in order to restore the machine to an uninfected state. When the executable of the malware was run on the windows host, the executable disappeared and the malware deletes itself from the folder. At this point the system was infected and Wireshark allows us to observe any suspicious activity. In Figure 1.3 is the output of Wireshark after the Max++ is executed. There is a query for “intensedive.com”. Also a standard query response from the ip address 64.74.223.42.
 |
| Figure 1.5 - Wireshark captures packets from the Windows XP system infected with Max++ |
We can get more information on the IP address and domain name by using the “whois” or “tracert” command on a Linux terminal. Also this can also be done on many hosting sites that provide a DNS lookup. Giuseppe Bonfa [2] in his article provides a trace on the crime ware origins of the Max++ malware and links it to the Russian Syndicate Network, which is a known friendly environment for malware.
3. File System and Registry Behavior
In the previous section we saw how Max++ has the ability to silently transmit data. Let us now analyze what files and registry items are modified by the malware. A simple way to get an initial report on a malware is to use free web services like Annubis, GFISandbox, and VirusTotal. These three services allow for web submission of the sample file. Both Annubis and GFISandbox actually run the malware in an isolated environment. They provide you with a quick analysis of the malware. Below I provide results for the Max++ malware from VirusTotal, GFI Sandbox, and Annubis.
3.1 VirusTotal Results for Max++
I submitted the Max++ executable to VirusTotal and in Figure 1.6 is the analysis summary. At the time of my submission 43 virus scanners were used by VirusTotal and 39 detected the file as malware. Also included in the summary is the SHA256 hash for the file as well. Figure 1.7 we have a list of all the virus scanners used and which scanners detected the virus. Each scanner has its own signatures and this table shows the benefit of utilizing many virus scanners. Not all virus scanners may detect the file as a malware.
 |
| Figure 1.6 - VirusTotal analysis summary for Max++ |
.png) |
| Figure 1.7 - List of antivirus scanners used by VirusTotal and the detection count |
Also provided by VirusTotal is a list of all the different filenames the malware has been submitted under.
 |
| Figure 1.8 - Other names that have been associated with the same malware by VirusTotal |
3.2 GWISandbox Results for Max++
I submitted the Max++ executable to GWISandbox and below are the results for my submission. GWISandbox actually runs the file in a remote isolated environment and is able to give you a quick analysis of the infected system.
Figure 1.9 shows the analysis summary returned by GWISandbox. The MD5 hash is provided for the file as well as the size and number of processes it starts on the system. The type of sandbox system is returned and in this analysis the malware was executed on a system with the Windows XP Service Pack 3. The number of processes that are run by Max++ is 3. Later in the detailed report of Annubis we are also given the name of the specific processes and the files they create, delete and modify. On the second table in Figure 1.9, the digital behavior traits section gives us an overview of the actions taken by the malware. The Max++ malware spawns new services, deletes the original executable, injects code, and modifies files and registries on the infected system.
 |
| Figure 1.9 - Analysis summary provided by GWISandbox |
Included in the report we have the files that are deleted by the malware. Figure 1.10 shows us that the original executable file is deleted by the same process.
 |
| Figure 1.10 - GWISandbox report of files deleted by the Max++ executable |
 |
| Figure 1.11 - GWISandbox report of files created and modified by Max++ executable |
Not only does the Max++ remove the original file that infects the system, it also creates and modifies files in the windows system folders. Specifically we can see in Figure 1.11 that three files are created in the Windows system32 folder. “afd.sys” and “afd.sys.new” is added to the drivers folder. “afd.sys.new” is also added to the “dllcache” folder in windows as well.
GWISandbox also presents us with the registry values that are set by the malware. Below in Figure 1.12 four modifications are performed. The first three modify a registry in the “ControlSet001” folder. It appears to add its own service “afd”, which we saw previously that Max++ created this file, to start on system boot. The fourth modification is to a registry for the Internet Explorer browser. This will most likely make browsing in Internet Explorer insecure. Also in Figure 1.12, under the network traffic table, we can see a connection is made by the malware to a remote IP “10.20.25.255”.
 |
| Figure 1.12 - GWISandbox report of registry files modified and network conections made by Max++ |
3.3 Annubis Results for Max++
Among the three online services to submit a malware sample and receive an analysis, I found Annubis to be the most complete and detailed report. The full report is extensive and I will only discuss a portion of the results in this section.
 |
| Figure 1.13 - Annubis analysis summary for Max++ executable |
The analysis summary of the report from Annubis can be seen in Figure 1.13. We are given a description of the actions Max++ performs as well as the risk, which is color coded and ranges from low to high risk. The first behavior observed by Annubis is that Max++ changes the security settings of Internet Explorer. This is supported by the GWISandbox analysis which reported a registry in the Internet Explorer folder had been modified. In Annubis this change is identified as a medium risk to the system. Annubis also reports that Max++ creates, modifies, and deletes files from the computer. It is classified as a high risk to the system. As seen by the GWISandbox report we know the original malware file is deleted and other files are added to the system folder. Also we know three processes are run by the Max++ executable and Annubis reports the same here. The last behavior observed is related to the registers that are read, created, modified and monitored by the malware. Annubis reports this behavior as a low risk to the system.
 |
| Figure 1.14 - Annubis analysis of modules loaded at execution of Max++ |
From Annubis we can also tell which modules are loaded at runtime of the Max++ malware. In Figure 1.14 we have a list of the loaded dll’s. Among them is “ntdll.dll” and we will later see, using a debugger, how the malware searches for this driver and creates its own functions to perform.
 |
| Figure 1.15 - Annubis analysis of the file activity for the Max++ primary process |
As we have seen from the initial summary by Annubis, three processes are executed by the malware. In Figure 1.15 we see file activity from the main process of Max++. The file “appcompat.txt” is created in a temporary folder. Also the main process reads data from the driver “winsock.dll”.
 |
| Figure 1.16 - Anubis analysis of processes started by the Max++ malware |
In Figure 1.16 we have a list of the new processes that are started besides the main process of Max++. Specifically, “dwwin.exe” and “drwtsn32” are two processes that are started by the malware. In comparison to GWISandbox, Annubis allows us to see not only the changes that are made by the main process of Max++, but the changes that are made by the child processes as well.
 |
| Figure 1.17 - Annubis Max++ analysis of registry modifications due to the dwwin process |
The process dwwin.exe is started by Max++ and Figure 1.17 displays all the registry modifications that are made by this child process. We are able to see the registry keys and new values that are created for each element. All the registries that are modified by this process have to deal with Internet Explorer and are likely crippling the security features of the browser.
 |
| Figure 1.18 - Annubis Max++ analysis of file activity by dwwin process |
In Figure 1.18 Annubis gives us the files modified by the “drwtsn” process. We have one dump file “7B563.dmp” that is created and later deleted from the temporary folder of the system. Also another file is deleted, “9ad1_appcompat.txt”. This information that was not presented by GWISandbox in the report it generated.
 |
| Figure 1.19 - Annubis Max++ analysis of registry values modified by drwtsn process |
A second process, “drwtsn”, is started by the Max++ executable. Figure 1.19 displays the registry changes that are made by this child process. “drwtsn” is a system file that is part of the windows operating system. The file is normally located in “C:\windows” or “C:\windows\system32”, however, malware is known to disguise as this system file [2]. Also in Figure 1.20 we have all the file changes performed by the “drwtsn” process. A new folder is created labeled “Dr Watson” and this folder is installed under the Microsoft directory. Here the executable, log, and dump file are created. The process also accesses information stored on the original Max++ executable file. Annubis also provides us with the file system control communication and the device control communication. The file “isarpc” is accessed three times, and the file “ksecDD” is accessed eight times in the Annubis analysis.
 |
| Figure 1.20 - Annubis Max++ analysis of file activity by drwtsn process |
4. Conclusion
To briefly summarize this section, Max++ is an advanced rootkit that creates, modifies, and deletes files/registries on a computer without the users consent. It opens network connections and the penetration of Max++ is extensive. I have presented several malware analyses from web services online and have presented the changes they report on an infected system. I will continue to delve into the code of the Max++ rootkit and analyze an anti-debugging technique frequently used by this malware.
5. References
[1] Dr. Xiang Fu, Malware Analysis Tutorial 1: VM Based Analysis Platform, Available at
[2] Guiseppe Bonfa, "Step-by-Step Reverse Engineering Malware: ZeroAccess / Max ++ / Smiscer
Crimeware Rootkit", Available at http://resources.infosecinstitute.com/step-by-step-tutorial-on-
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.