Practical Malware Analysis - Lab 7

Jan 12, 2021
6 min read

Analyzing Malicious Windows Program

Lab 7

The goal of this lab is to help understand how a malware interact with the operating system.

Lab 7-1

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

In the main function, there is a StartServiceCtrlDispatcher API call which allow to connect the thread of a service process to the service control manager. The name of the service is MalService.

MSDN_StartServiceCtrlDispatcher

Futhermore, a subroutine is call at 0x401040.

call_sub_401000

Within this routine the function starting at 0x401064 show the creation of a service persisting on the system. The OpenSCManager call is used to open the service control manager.

open_sc_manager

MSDN_OpenSCManager

Then MalService object will be added to this control manager with CreateServiceA.

MSDN_CreateServiceA

create_service

Why does this program use a mutex ?

Mutex are used to be sure that only one instance of a program is running at the same time.
So Mutex are really usefull for malware writers because you can see if you have already infected a victim.
In this example, the malware try to open a mutex call HGL345. If he can it means that there is already a mutex HGL345 on the target system, otherwise it goes to 0x401064 and create the Mutex.

mutex

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

The mutex HLG435
The service call MalService

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

At 0x40112C the function StartAdress is call before creating a thread.

network_signature1

Within this function we can see that the user-agent: Internet Explorer 8.0 is used to open a browser. Next, the malware call the URL http://www.malwareanalysisbook.com

network_signature2

At 0x40116D, it looks like an infinite loop that try to access to the URL (there is no jump out of here).

What is the purpose of this program ?

The malware persist on the system by creating a process call MalService if an instance of the program isn’t already working. This is accomplished with the use of a mutex call HLG435. Then it create a timer that wait the year 2100 before going to StartAdress.

timer

It open a browser with the user-agent Internet Explorer 8.0 and start an infinite loop by communicating with http://www.malwareanalysisbook.com. We can presume that if a lot of computers start this program, the 1st january 2100 the website will be DDOS (or attend unexpected huge traffic).

When will this program finish executing ?

Obviously this program never end. There aren’t any jump out of the sleep function.

Lab 7-2

How does this program achieve persistence ?

I don’t see anything that could say the program achieve persistence. What we can presume is that the program use COM Objects (Component Object Model) to do his job. The obvious OleInitialize is a pattern to start using those objects.

MSDN_OleInitialize

ole_initialize

What is the purpose of this program ?

This malware initialize a COM library in the first part of the program. Then it create an object with CoCreateInstance. A copy of the string http://malwareanalysisbook.com/ad.html is made with SysAllocString that will probably be used by COM. To sum up, the malware use COM object to bring the user to an advertisement web page.

MSDN_CoCreateInstance
MSDN_SysAllocString

behaviour

When will this program finish executing ?

This program ends when the advertisement is open. There aren’t any other way to terminate the malware.

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. Warning: This lab may cause considerable damage to your computer and may be difficult to remove. Do not run this file without a virtual machine with a snapshot taken prior to execution.

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

Within the main function there is reference to a native Windows DLL: Kernel32.dll. The program create the DLL in C:\Windows\System32\

kernel32

Then it create another one: Lab07-03.dll. Don’t forget, the executable and the DLL were found in the same directory on the victim machine.

Deeper in the function, we can see a copy of the Lab07-03.dll into C:\Windows\system32\Kerne132.dll (notice the 1 instead of l).

copy

At 0x4011E0, there is a call to a function taking a strange parameter: C:.

c_directory

The program try to search a file in the path given in parameter.

argv_4

It can travel from directory to directory with ”." and ”.." that are usefull for the system.

directory_travel_1

directory_travel_2

Then there is a comparison with the extension “.exe”. We presume that the program search for executables before doing things with them.

executable_extension

Here is the comparison that is made to see if the file discover in directories executables. If it does it will call a function at 0x4010A0.

comparison

Inside the routine, we can see that the program call 3 API:

CreateFileA
CreateFileMappingA
MapViewOfFile

api

Based on this we can infer that if an executable file is located, it is mapped into memory then modified. Further in the program we can see IsBadReadPtr API call which is used to check if the program read a specified range memory. Previously we saw that every executables are map into memory, now we know that is used to browse inside their memories.

MSDN_IsBadReadPtr

Next we can see the program comparing the strings “kernel32.dll” with the output of IsBadReadPtr. The program try to find the string inside the memory of executables.

compare_kernel32

I wasn’t able to determine easily what was done next by the malware. I used some ressources on the Internet to found that at 0x40118C, there was an ASCII strings that was “obfuscated” with hexadecimal values. By pressing A on this string you can convert it. The result is: kerne132.dll.

modification_kerne132

In the end of the function, we can see a loop. The program compare every executable that he founds in the C:\ directory, then it check if the executable use kernel32.dll and change it to kerne132.dll to persist on the system.

Now let’s deep analyze the DLL. The DLL is used to create the mutex SADFHUHF in order to see if the victim is already infected. If it can open the DLL it jump directly to the end of the program.

dll_mutex

Otherwise, it create a mutex

dll_mutex_create

Then the program call WSAStartup. This function prepare the system to create a socket. If the function success, it jump to 0x1000108C. prepare_socket

MSDN_WSAStartup

The socket is create to communicate with the C2 (127.26.152.13).

socket_communication

The malware send Hello to the server, if no errors occurs during the send, the malware wait for a response. Then it sleep and loop again until a response. Alternatively, if the send fail, the program close the socket and end.

socket_communication2

Commands send from the C2 are compared to a string. Depending on matches the malware does things like:

sleep
exec a command

compare_commands_c2

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

Directory: C:\
Search for .exe in the above directory
DLL: kerne132.dll (in the PE)
Mutex: SADFHUHF

Network signature (Not ask):

C2: 127.26.152.13

What is the purpose of this program ?

This program is able to persist on the system by hijacking the native kernel32 dll with a fake one kerne132. With this new dll the malware can sleep or execute command directly from the C2.

How could you remove this malware once it is installed ?

This program will be very difficult to remove because it infect every executables in your C:\ directory. A solution could be to reverse the process used by the malware and replace every fake kernel32.dll with the native one.