Lab 7-1

Pfew, let’s keep going!

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

Questions

1. How does this program ensure that it continues running (achieves persistence) when the computer is restarted?

This program ensures that it continues running by creating a service known as Malservice.

Figure 1.1

1. Why does this program use a mutex?

This program uses a mutex to ensure that there aren’t more instances of the same malware running. The functions required to check for a mutex can be seen in Figure 2.1.

Figure 2.1

1. What is a good host-based signature to use for detecting this program?

Good host-based signatures are the mutex named HGL345 and the service MalService.

1. What is a good network-based signature for detecting this malware?

A good network-based signature for detecting this malware is the Browser-Agent Internet Exporer 8.0 that sends requests to www.malwareanalysisbook. com.

1. What is the purpose of this program?

The purpose of this program is to run a DDOS attack to the URL mentioned above.
After checking if another instance of the program already runs and establishing itself as a service running at boot, it creates a wait timer until 1st of January 2100, as seen in Figure 5.1.

Figure 5.1

Next, in Figure 5.2, we can see that it creates a thread 20 times.

Figure 5.2

The lpStartAddress argument points to a loop that performs an unconditional jump, meaning that this loop will run forever, downloding the www.malwareanalysisbook.com URL. (Figure 5.3)

So, 20 threads will be downloading that page forever resulting in a DDOS attack.

Figure 5.3

1. When will this program finish executing?

This program will never finish executing. It waits until 1st of January, 2100 when it will create 20 threads that run in an infinite loop.

#Keep reading after the questions for a detailed anaylsis.

#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.

Questions

1. How does this program achieve persistence to ensure that it continues running when the computer is restarted?

This program achieves persistence by modifying every executable on the system to run the malicious Lab07-03.dll (seen as kerne132.dll on the host).

1. What are two good host-based signatures for this malware?

One good host-based signature for this malware is the presence of a mutex named “SADFHUHF”, as seen in Figure 2.1.

Figure 2.1

Another really good host-based signature is the presence of kerne132.dll on the system.

1. What is the purpose of this program?

The purpose of this program is to create a persistent way to have access to the infected machine and send two instructions: one to sleep and another one to execute a command.

1. How could you remove this malware once it is installed?

This program is difficult to remove, as it modifies every executable on the system. The easiest way out is to restore from a backup.

Another way can be to copy kernel32.dll and name it kerne132.dll, but I am not sure how it will hold into the future.

Detailed analysis

Lab07-03.dll analysis

After creating the mutex, the sample uses socket-specific functions in order to establish a connection to “127.26.152.13”.(Figure 5.1)

Figure 5.1

Afterwards, it sends “hello” as a message back to the hacker to let him know that it has been successful so far and that it can send further commands.

Figure 5.2

Then, the malware receives commands through the same socket. The sample checks if the command is received is “sleep” or “exec”. In case of the first one, it will sleep for 60s. Upon receiving “exec” as a command, the malware will then proceed to create a process. As of the .dll it is not clear what this process is. (Figure 5.3)

Figure 5.3

In the end, it will close the socket and shutdown the connection.

Lab07-03.exe analysis

At the very beginning, we can see in Figure 6.1 that the program checks if there are two arguments upon calling it. If there are not 2 arguments at the moment of executing the program, it will just terminate itself.

Figure 6.1

Next, in figure 6.2, there is a loop that is checking if the argument specified is “WARNING_THIS_WILL_DESTROY_YOUR_MACHINE”

Figure 6.2

Up until now, we know that if the program is not run with the above mentioned argument, it will just exit.

Upon correctly executing, it will run Kernel32.dll to open Lab07-03.dll, as seen in Figure 6.3.

Figure 6.3

Then, there are a lot of mathematical operations performed and a few functions called that we can look into in Figure 6.4 and Figure 6.5. I’ve named them boring_maths as they are not of any importance right now. (haha)

Figure 6.4

Figure 6.5

In the end, in Figure6.6, things start to become a lot more interesting. We can see that the program stopped writing into the files, as it closed the handles. Then, it copies our malicious dll, Lab07-03.dll into C:\Windows\System32*kerne132*.dll in an attempt to make it look like the legit file, kernel32. This is also called masquerading, a devense evasion tactic, documented in the MITRE Framework. (Check it out if you haven’t already!! https://attack.mitre.org/matrices/enterprise/)

Figure 6.6

Next, we see that the string “C:\” is pushed onto the stack before calling the sub_4011E0 function. Let’s look into that now!

The first function called is FindFirstFileA with the above found argument. Then, a bunch of other math operations are being made.

Figure 6.7

Subsequently, we find a call to stricmp. A string is being compared with .exe (Figure 6.8). We then find sub_4010A0.

Figure 6.8

Now, what we find interesting in here is the stricmp function between kernel32.dll and another string. The repne scasb correspons to the strlen function and the rep movsd to the memcpy function.

Figure 6.9

Looking into the offset dword_403010 we find that it’s hex value starts with 3. Hex values beginning with 3, 4, 5, 6 or 7 are ASCII characters. By Pressing A on the keyboard with our cursor on the dword_403010 value, IDA will convert the data into the string kerne132.dll.

Figure 6.10

Finally, we understand that it will replace the kernel32.dll string with kerne132.dll with the fake dll that was placed in C:\Windows\System32.

Going back to our function, we encounter a call to our sub_4011E0 function, meaning that the studied function is a recursive one.

Figure 6.11

We can now, finally, make an assumption regarding the behaviour of this malware.

The malware will look for all the executables (.exe) in systems that have kernel32.dll in their memory and replace it with kerne132.dll. It does this so that any executable that runs on the system access kerne132.dll instead of kernel32.dll.