Malware is one of the most common problems for the average computer user, which can result in unexpected behavior, slow response times, and possible privacy or data breaches. While the typical user may spend their time trying to remove malware, security researchers spend their time exploring the inner workings of these programs. This process is called reverse engineering which focuses on finding out exactly what these programs do, how they do it, and how to recognize or defeat their malicious actions. This work can lead to better antivirus software which, in turn, can recognize and stop malware from running and as well as even reverse damage done to the infected computer.
This post analyzes the execution and effects on a user’s computer from the malware that appears as a fake antivirus program named “XP Anti-Spyware”. We reverse engineered the executable to give an in-depth look at its unpacking process and low-level operation. Finally, the key validation process is reverse engineered and modified to accept any string as a valid key.
The malware this document will analyze has a SHA256 sum is 57cfaacdad1370beac5b9b9ebc0cc7df7333148d83ec8771c66b07294fb15eb1
The malware requires administrator privileges to execute successfully on the host computer. This replicates a common execution environment due to many Windows users using their administrator accounts for daily use. Upon the malware’s successful execution, it installs another piece of malware and then runs it with the newly gained administrator access. The malware intended to be run by the user will be referred to as malware “A”, while the malware installed by malware “A” will be referred to as malware “B”.
This malware analysis was originally done on a Windows 10 virtual machine using VMWare Fusion 8. In this environment, malware “A” would run for a few seconds, delete itself, and then terminate the process. No notable effects were observed during the execution; however, PE View was used to further inspect the PE header for additional within the PE header. The data contained within the PE header is shown in Figure 1. Furthermore, I confirmed the malware was a 32-bit Windows executable and noticed the compilation date was February 24, 2011. This led me to consider the malware was running on Windows 10, which had not been released at the time of its compilation.
Noting that Windows XP was running on 45.3% of computers in February 2011, I decided to use a Windows XP VMWare virtual machine as the analysis environment . This proved to provide an acceptable platform to allow the malware to run as intended.
Malware A Execution and Malware B Creation
After running Malware A, a hidden executable named with three random lowercase letters is created in C:\Documents and Settings\USERNAME\Local Settings\Application Data. Figure 2 shows an instance where it is named opk.exe. This newly created malware will be referred to as malware B.
During its execution, malware A also edits the registry using Windows API calls to allow firewall exceptions, disable firewall notifications, disable the firewall, disable Windows Update notifications, and disable notifications about the lack of antivirus software. Lastly, malware A runs an instance of malware B.
Malware B Execution
Malware B begins execution after its executable is created and called by malware A. Malware A then terminates and it is deleted by the malware B process. The following sections describe the operations of malware B.
Malware B makes numerous DNS requests shortly after it begins to execute. These domain names seem random, but have been verified to be in a consistent order by comparing these requests in multiple separate executions.
Process Monitor, a program in the SysInternals suite, shows all actions a program performs such as writing to files or making network connections, which is helpful when exploring what malware does. Figure 3 shows Process Monitor capturing malware B making several DNS requests indicated by its use of the domain service at the end of the line.
After viewing the network traffic using Wireshark, I used whois lookups to find the DNS records for each site and found that none of the domain names were still registered. Some of the domain names requested include jaf******.com, jer******.com, cix*****.com, and bem******.com. An example of the DNS traffic generated for other requested domains is shown in Figure 4. I looked up these domain names’ historical DNS records, and many of them were first registered in August and September of 2011 . Because this is nearly six months after the malware was supposedly created, this could indicate that the malware had an active lifespan of several months up to a year.
Malware B also closes several HTTP connections. Each of the IPs are listed in the table following table along with a description. Reverse DNS searches on each IP yielded no useful information.
The malware closing Microsoft connections might have to do with the malware disabling Windows Update. This would prevent Windows from receiving any updates which would normally improve secuirty which could possibly disable the malware.
The main user interface of malware B appears and begins to scan the filesystem by iterating through all the folders in the filesystem. It will randomly report false malicious files that don’t exist and give them a random classification and description shown in Figure 5.
After the malware is done scanning and falsely reporting malicious files, it gives the user the option to register the software shown in Figure 6. However, upon clicking the register button, the program terminates. The cause of the termination is unclear.
Every other button in the program prompts the user to purchase the full version or enter an activation key shown in Figure 7. Upon clicking the “Purchase full version” button, the user is taken to the site that responded to one of the DNS requests at the start of malware B. These sites were presumably the fake storefronts to purchase “licenses” for this malware.
One user reportedly paid $79.95 for a key to get rid of the malware which reported as a charge from “Albinosdefender. com Baku” .
Malware B edits the registry keys pertaining shown in Figure 8 to the start menu shortcuts to internet browsers so that they point to malware B and pass “-a” and the browser executable as command line arguments.
When using the start menu to start any popular browser such as Internet Explorer, Firefox, Chrome, or Opera, the shortcut opens an instance of malware B instead, which provides an alert shown in Figure 9 prompting with the malware activation window in Figure 7.
Windows Security Center Imitation
Malware B imitates the Windows Security Center that is used to access security-related settings within Windows XP such as the firewall, Windows Update, and antivirus programs. When malware B runs, it kills the legitimate wscntfy.exe (Windows Security Center) process and loads an imitation version of the Windows Security Center.
The imitation security center in Figure 10 looks exactly the same as the legitimate version in Figure 11, except it removes the option to manage Windows Update and Windows Firewall, falsely reports that Windows Update is enabled, and adds a shortcut to malware B named “XP Anti-Spyware”. Functionally, it modifies all of the links in the window to point to malware B.
This malware was quite difficult to reverse engineer using traditional static analysis. Both malware A and malware B use executable packing making their normal executables unproductive to be statically analyzed. This forced much of my time to be spent doing dynamic analysis and by viewing Windows API calls made by this program during execution using Process Monitor from the Sysinternals suite. This section describes the methods used in and findings of my analysis.
Using Dependency Walker, a program that shows functions imported from dynamically linked libraries (DLLs), I first viewed the imported DLLs in malware A shown in Figure 12 to get a general idea of the capabilities of the program. WININET.DLL and WSOCK32.DLL both indicate that this program uses networking. GDI32.DLL indicates it is a graphical application. The rest of the DLLs are fairly common among most Windows programs. These imports led me to begin my static analysis by finding uses of networking functions in the executable.
I began my static analysis by looking through the malware in IDA Pro attempting to find cross references to networking functions I understood well. This yielded no results as I found that nearly all of the functions imported from DLLs had no references in the code. Because they must be referenced during runtime at some point, I began exploring the malware for obfuscation tactics.
When performing static analysis on the executables of malware A and malware B, the executables had intriguing memory profiles shown in Figure 13. The majority of the executables were empty .data sections pictured in tan. This, in conjunction with having a very small and simple .text section, led me to believe that packing was involved.
Their identical IDA Pro profiles also led me to discover that they were actually the same file. This was verified by the matching SHA sum of malware B to the SHA sum of malware A. Because both of the files are the same malware, this analysis will refer to them singularly as “the malware” hereafter.
My first attempt at obtaining an unpacked executable was using a tool called Volatility. Volatility is a tool that can be used to extract executables from volatile memory, which was helpful in this case because it works with VMWare memory snapshots .
To get the malware process in a memory image to be extracted, I ran the malware until it was in the process of scanning the filesystem and then took a snapshot. I then used Volatility on the .vmem (VMWare memory image) containing the malware to extract the process.
At the bottom of Figure 14, we see that the yxg.exe executable was successfully extracted to executable.496.exe
However after examining executable.496.exe in IDA Pro, it proved to not work as intended as the entire executable was empty shown in tan and black in memory profile shown in Figure 15. To be sure that I was not operating Volatility incorrectly, I extracted another process using the same method and it produced a full executable on which I could do static analysis.
The second attempt at obtaining an unpacked executable used a tool called OllyDumpEx, which is an add-on for Immunity Debugger/OllyDbg that can dump the currently debugged process into a .exe file .
To get the process into memory to be extracted, I ran the program until it was scanning the filesystem, which was a time I suspected it would have been fully unpacked. I then attached Immunity Debugger to the process and attempted to dump it using OllyDumpEx.
Using the default options of OllyDumpEx as pictured in Figure 16, I dumped the process. Note that this dump only includes the malware’s memory space and not any loaded dynamic libraries. This generated a file called eff_dump.exe which I then examined in IDA Pro.
The memory profile of eff_dump.exe pictured in Figure 17 looks just as expected. The blue located toward the right of the bar shows identified functions. The memory space that these new functions are located in was empty during the analysis of the .exe before execution meaning that section of executable code was unpacked into memory at runtime. This is further confirmed by the beginning of the program being rewritten to a single jump instruction to this newly written area of memory.
The downside of this unpacked executable is that it includes no named references to imported DLL functions. In place of the name of the function, it simply has a reference to memory in which the DLL was loaded while it was executing. Because IDA Pro has no way of knowing what DLL was loaded at the addresses these functions reference at runtime, I had to name these functions by walking through their execution in IDA Pro, look up any references to a DLL function in the paused process in Immunity Debugger, and rename them manually in the IDB. This significantly hindered the speed at which I could reverse engineer the malware using static analysis.
I made several attempts to dump the executable with a correct import table so that IDA Pro could correctly recognize the functions imported from DLLs to no avail. This included trying numerous combinations of OllyDumpEx options such as including the DLL memory space in the dump and using tools to rebuild the import table such ImpRec, but nothing worked as intended forcing the manual function naming.
Though the majority of the functionality was described in earlier, this table contains specific functions identified in IDA Pro, their unpacked address, and a short description
I noticed that the malware made several TCP reconnects to any domain from Figure 4 that was resolved. I found this out by editing my hosts file so that it would resolve one of the domains requested by the malware to point to an easy-to-recognize address. I chose to resolve fyt******.com to 220.127.116.11 in this example shown in Figure 18.
After running the malware and viewing the network traffic in Wireshark, I confirmed that the malware made requests to the IP I had set the domain to resolve to in the hosts file shown in Figures 19 and 20.
The interesting thing about all of these requests is that they had no content. It simply kept repeating TCP reconnects. I concluded that these connections act as a type of ping for the malware owner to keep track of infected hosts.
When clicking on the “Purchase Full Version” button in the window pictured in Figure 21, the malware makes an HTTP GET request to the resolved domain for a page that acts as a unique machine identifier.
This was discovered by setting up the hosts file to point fyt******.com to the localhost and running a local Python SimpleHTTPServer on port 80 to view requests made. Figure 22 shows the malware made a request to fyt******.com for the page /10170003131137353284.
My final objective was to modify the malware to get it to believe that a valid key had been entered to see how it behaved. I began this process at the key entry screen in Figure 23.
After entering an incorrect key, the program will provide an “Invalid registration key” error message shown in Figure 24.
To begin reverse engineering the key validation, I attached the debugger to the malware when this message box popped up and analyzed the function call stack shown in Figure 25. If the malware was going to provide an error message, it must have checked the password somewhere to know it was invalid.
Examining each function led me to look at function 0x5C9F7A which included a call to GetWindowTextA highlighted in Figure 26. I concluded this was the call to get the user’s registration key from the window before it ran, so I set a breakpoint and stepped over this function, which confirmed this function gathered the text from the user’s input.
I then followed the program’s use of this input text to see where it was compared. It is used as an argument in a call to 0x5C6F3B which returns the length of the key and subsequently compares it to 16. I’m assuming the program expected the registration key to be 16 characters long.
A few jumps after the comparison to 16, there is an instruction that jumps to 0x5CA214 shown in Figure 27.
After that jump, the code to present the user with the error message shown in Figure 28 is executed.
By simply inverting the conditional jump at 0x5CA047 to a JNZ shown in Figure 29, we can trick the malware to thinking that it has received a valid key.
Running the malware after making this change allows it to run as it would with a legitimate key. A window presenting the entered key appears and hitting continue begins the “uninstallation” of the malware shown in Figure 30.
A progress bar appears and pretends to remove the malware shown in Figure 31.
Afterward, it brings up a window that updates the fake antivirus Figure 32.
It attempts to download another executable from anti******.com, however, the site responds with an error. This request was captured in Wireshark shown in Figure 33.
The fake antivirus then reports that the computer has been cleaned shown in Figure 34.
Note that the malware does not stop running or remove itself after inputting the correct key.
This analysis covered nearly all aspects of the malware: basic operation, method of infection, network connections, basic static analysis, and key validation reverse engineering. This malware used many tricks to intrude upon the normal usage of the infected host, but nothing particularly advanced. In essence, the malware was a combination of links to point to a website in which the malware author would receive money in return for sending a key to get rid of annoying popups and messages. However, defeating this key validation of this malware was as simple as changing one instruction. Malware like this seems to be a precursor to modern ransomware because it provides the means to infect a system without the actual manipulation of files. This analysis proves that malware is nothing more than a program like any other using clever deception to trick a user out of money, time, or information.