8 minute read


Chapter 7 of the Practical Malware Analysis book covers some unique ways that malware uses Windows functionality. The chapter starts off with an overview of the most common Windows API terminology, such as the Hungarian notation, handles, and file system functions. It then moves on to the registry, networking API’s, and ways for malware to transfer access to code outside a single file. The chapter closes off by discussing Kernel mode versus User Mode and why the Native API is popular among malware writes. This chapter consists of 3 lab assignments, of which the final lab is a lot tougher than the other labs covered so far.

Lab 7-1

Analyze the malware found in the file Lab07-01.exe.

1. How does this program ensure that it continues running (achieves persistence) when the computer is restarted?
Answer: When viewing the malware in IDA, we see references to a service in the main function:
On our dynamic analysis machine, we can confirm that it created a new service named “Malservice” that automatically starts the Lab07_01.exe program to achieve persistence:

2. Why does this program use a mutex?
Answer: When analyzing the first function call in main, we see that the program tries to open a mutex named HGL345 using OpenMutexA. There are only two possible outcomes: the program either calls ExitProcess or creates the HGL345 mutex and continues execution. This indicates it is using a mutex to ensure that only one version of the malware is running at a time.

3. What is a good host-based signature to use for detecting this program?
Answer: The mutex named HGL345 and the service named Malservice.

4. What is a good network-based signature for detecting this malware?
Answer: While launching the malware on my dynamic analysis VM, I noticed that it made a request to www.malwareanalysisbook.com.

Going back to IDA, we see that this URL is being used in the StartAddress function:
If we look at the xrefs to this StartAddress function, we see that it is being used to create a thread.
Execution of a thread begins at the start address and continues until the function returns. Looking at the start address, it doesn’t seem to return at all. Notice the arrow that points back up and the jmp instruction at 00401180. This is a loop that keeps connecting to the www.malwareanalysisbook.com URL.

Another thing that we notice in this thread is the User Agent Internet Explorer 8.0 that is being used. Both the URL and the user agent can be used as network-based signatures.

5. What is the purpose of this program?
Answer: The program creates a mutex named HGL345 to ensure that only one instance of the malware is running at a time. It then creates a service named Malservice, that will automatically run the Lab07_01.exe file at reboot to achieve persistence. The service uses a thread that connects to the www.malwareanalysisbook.com page using the user agent Internet Explorer 8.0 in an infinite loop.

6. When will this program finish executing?
Answer: The program does not seem to terminate at all.

Comparing my answers to the Lab 7-1 solutions

Conclusions after comparison:

  • This malware indeed seems to connect to www.malwareanalysisbook.com forever, indicating a DDoS attack. But there are two important things that we missed in our analysis:
    1. The code in the snippet below sets the program to wait until January 1, 2100

      • Notice how after the xor edx, edx instruction, the SystemTime.Year,DayOfWeek,Hour and Second all get set to the value of EDX. This is equal to 0
      • Then, the SystemTime.Year gets set to 834 (hex), which is 2100 in decimal.
    2. The code then uses ESI as a counter to 14 (hex), which is 20 in decimal. The code snippet below shows us that CreateThread is called 20 times.

      • This means that 20 threads will call www.malwareanalysisbook.com forever on January 1, 2100!

Lab 7-2

Analyze the malware found in the file Lab07-02.exe.

1. How does this program achieve persistence?
Answer: The program does not seem to achieve persistence at all. It exits after running.

2. What is the purpose of this program?
Answer: This program uses the Component Object Model (COM). COM is an interface standard that makes it possible for different software components to call each other’s code without knowledge of specifics about each other. Each thread that uses COM must call the OleInitialize or ConInitializeEx function at least once prior to calling any other COM library functions. The imports table of this program shows OleInitialize:
After running the program in our dynamic analysis VM, we conclude that it uses COM to display the http://www.malwareanalysisbook.com/ad.html web page.
From a static analysis point of view, we can also see this URL after the call to VariantInit

3. When will this program finish executing?
Answer: The program finishes executing after opening the http://www.malwareanalysisbook.com/ad.html URL.

Comparing my answers to the Lab 7-2 solutions

Conclusions after comparison:

  • No differences here!

Lab 7-3

For this lab, we obtained the malicious executable, Lab07-03.exe, and DLL, Lab07-03.dll, prior to executing. This is important to note because the malware might change once it runs. Both files were found in the same directory on the victim machine. If you run the program, you should ensure that both files are in the same directory on the analysis machine. A visible IP string beginning with 127 (a loopback address) connects to the local machine. (In the real version of this malware, this address connects to a remote machine, but we’ve set it to connect to localhost to protect you.)

Warning: This lab may cause considerable damage to your computer and may be difficult to remove once installed. Do not run this file without a virtual machine with a snapshot taken prior to execution.

This lab may be a bit more challenging than previous ones. You’ll need to use a combination of static and dynamic methods, and focus on the big picture in order to avoid getting bogged down by the details.

1. How does this program achieve persistence to ensure that it continues running when the computer is restarted?
Answer: I was unable to figure this out with just static analysis of the malware. I could not get the program to run on my dynamic analysis machine. The main function shows that it requires a parameter to run. Notice that argc is compared to a value of 2:
The program name Lab07-03.exe will be counted as the first parameter. So we know that we need to supply this program with just one parameter to get it to run successfully. But I couldn’t figure out what this parameter should be. If the correct parameter is not supplied, the program simply exits.

From static analysis I learned that the program copies the Lab07-03.dll file into C:\windows\system32\kerne132.dll. Notice the number “1” instead of the letter “L” in “kerne132.dll”:
I suspect that the program uses this DLL file in some way to achieve persistence.

2. What are two good host-based signatures for this malware?
Answer: Lab07-03.dll gets copied to C:\windows\system32\kerne132.dll. Notice the number “1” instead of the letter “L” in “kerne132.dll”. C:\windows\system32\kerne132.dll is our first good host-based signature for this malware.

The second good host-based signature is SADFHUHF, which is a mutex that the DLL uses:

3. What is the purpose of this program?
Answer: Further static analysis shows that the DLL file creates a socket. It imports functions from WS2_32.dll for this:
The pushes before the call to socket are 6, 1, and 2:
Reviewing the Microsoft documentation for the socket function, we learn that the protocol is TCP (6), the type of socket is SOCK_STREAM (1), and the address family of the socket is IPv4 (2). Let’s change these values in IDA:
Following the code execution flow, we learn that the program connects to 127.26.152.13 over port 80:
After it connects, it sends “hello” to the malware operator:
Notice that it uses the offset to buf for this. buf is also used for the call to recv:
It looks like buf is being used to receive a command with a length of 0x1000 (4096 in decimal). Whatever is stored into buf gets compared to “sleep” or “exec”:

This seems to be the most important purpose of the program. Based on the command that it receives in this socket, the malware either sleeps or executes something.

4. How could you remove this malware once it is installed?
Answer: Since I couldn’t 100% figure out the persistence mechanism that this malware uses, I am unable to answer this question. Backups are never a bad idea however, so restoring from a backup would be my safest bet.

Comparing my answers to the Lab 7-3 solutions

Conclusions after comparison:

  • I was very close with my assumption that the program achieves persistence by using the C:\windows\system32\kerne132.dll file. The malware actually modifies every single .exe file on the system to import this malicious DLL file.
  • My answers to the other questions were correct. I did NOT see that coming, since I was only able to perform static analysis on the program. The program is very hard to remove because it infects every .exe file on the system, so restoring from backups is also the solution provided in the book!
  • Another interesting solution provided to remove the malware, is to copy the non-malicious kernel32.dll and renaming it to kerne132.dll.
  • The parameter that needs to be supplied in order to run the Lab07-03.exe is actually easier to find than I thought. It is located right under the mov eax, [esp+54h+argv] instruction:

    • This means that the malware could be run by entering Lab07-03.exe WARNING_THIS_WILL_DESTROY_YOUR_MACHINE, which makes dynamic analysis possible.

Sources

You May Also Enjoy

Retrospect and future plans - Pt. 2

8 minute read

A new job, graduation internship, a shift of focus towards Android malware analysis, and more… It’s been about 6 months since I posted one of these, so I gue...