Static analysis is the safer kind of analysis when it comes to malware. Static meaning that we are not running the malware binaries on our systems, but instead we are just looking at the code itself and the files’ characteristics. It is important to note here that the malware I’ve been using is for running on Windows XP, which is lovely. Even though this operating system is dated, there are still a multitude of tools that can be used for static analysis, including: VirusTotal.com, Md5deep64, Strings, PEiD, upx, Dependency Walker, PEview, and IDA Pro. Typically, many of these tools will show some of the same things, but that can be used to your advantage to confirm your findings and provide multiple sources to prove your claims.
So, let’s try taking a look at a file called “Lab07_01.exe”. First, always ensure you have a snapshot of your VM totally clean to revert to when needed. Next, VirusTotal.com is a great resource to check if your file gets picked up by different anti-virus software. For this file, I found that it has indeed been able to be flagged by many vendors as malicious:
On VirusTotal, under details, I was able to see the MD5 hash, which was: c04fd8d9198095192e7d55345966da2e. I tend to confirm the hash on my own VM as well using the md5deep64 hashing program, which produces the same hash (in this case):
Strings is a really interesting CLI program on Windows that searches an executable for any strings in either ASCII or Unicode format in the hopes of getting hints about the executables functionality. When run, it outputs a lot of strings. Some are complete nonsense and can be ignored. For “Lab07_01.exe”, some of the interesting strings we see are “OpenMutexA”, “CreateServiceA”, “Malservice”, and “http://malwareanalysisbook.com”. This could suggest the file opens mutexes, creates services, and tries to talk to a web server.
Now, I want to ensure the file we are analyzing is not obfuscated or packed in any way that could prevent me from getting information from it or running it. Since I got so many strings back in the Strings program, I can assume it is not packed. However, there are other programs that can confirm the file is not packed. PEiD can detect the compiler or packer of a program if it exists. In this case, we see the compiler is Microsoft Visual C++ 6.0, meaning although this file was compiled, it does not appear to be packed.
We can take this another step further to confirm the file is not obfuscated/packed in PEview. We can look at each section header to compare the Virtual Size and Size of Raw Data. If they are similar in each header, then it is likely the file is not packed/obfuscated. In this case, these sizes are pretty similar, which backs up the file not being packed.
Another cool thing we can see in PEview is when the file was compiled. In the IMAGE_FILE_HEADER, we can see the Time Date Stamp: 2011/09/30 Fri 19:49:12 UTC.
The last program I will use to confirm we are not dealing with a packed file, we can always attempt to unpack it using upx, the command line utility on Windows. Since the unpack using upx was unsuccessful, I can say it was not packed. I’ll stop boring you all with this part 🙂
Moving on, I want to find out what dynamically linked functions are called by this malware file in Dependency Walker. These functions can tell me what kind of behavior the malware file has when it is executed. In “KERNEL.DLL”, I can see the core functionalities which include: creating and opening a mutex, getting strings, getting processes, sleeping, and setting a timer.Â
Next, the “APVAPI32.DLL” which shows advanced core Windows components, shows the functions: “CreateServiceA”, “OpenSCManagerA”, and “StartServiceCtrlDispatcherA”, which suggests this file is itself a service.Â
“WININET.DLL” contains higher level networking functions that implement protocols like FTP, HTTP, and NTP. The functionalities I find here include opening the internet and opening the internet to a specific url.
So I can see what some of the functionality this file has, what about the files code? Well, I can use IDA Pro to view the static assembly code and trace execution. We first find the main function and start following calls to other functions.
This main function calls “StartServiceCtrlDispatcherA” which is a function used to implement a service (and also the same function found in Dependency Walker) and specify the function the service control manager calls, which is the function at sub_0x401040. Following this function, I found the program creating a mutex named HGL345 which ensures only one copy of this executable file runs at a time.
Continuing to follow the code, we can see “OpenSCManager” (program can add/modify services) is called , “CreateServiceA” (creates the service) is called, a date/time is set as January 1, 2100, “CreateWaitableTimerA” (create timer) is called, “SetWaitableTimer” (timer set) is called, and finally “WaitForSingleObject” (wait until set time) is called and set. This tells us that this program waits until January 1, 2100 to proceed in execution.
Now, at address loc_401126 I can see that 20 threads are created in a loop.
Following “StartAddress”, I can see that “InternetOpenA” and “InternetOpenUrlA” are being called with the destination being “http://www.malwareanalysisbook.com”. The jmp toward the end enforces a loop that will last forever. Meaning, each thread will continually download “http://www.malwarenalysisbook.com” forever.
Now, from what I could find in just the static analysis of this malware file, I can say this file gets installed on a system, creates a service so that it runs every time the host is booted, only allows for one copy of itself to run at a time (due to a mutex), triggers at January 1 2100, and launches a DDoS attack against “http://www.malwareanalysisbook.com”.
We were able to find all this through just static analysis, where I did not run this file at all, but only looked at its characteristics and code. To ensure what I found is indeed correct, it would be useful to continue this analysis using dynamic analysis…but that’s for another day.
