Learning of malware analysis. Solving labs from the "Analyzing malicious Windows programs" chapter from the "Practical Malware Anlysis" book

Hello!

I have to tell you that this chapter was the best that I've read since the beginning of the book. The information and tricks presented in this part of the amazing lecture made me happy. I'm sure that the labs will be as exciting as the whole chapter and I'm looking forward to solving them. As the title suggests, "Analyzing malicious Windows programs" chapter is all about the Windows OS internals useful primarily for the malware writers and thus for malware analysts too. Without further ado, I bring to you my solutions for the labs. Enjoy!




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Lab 7-1
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?

2. Why does this program use a mutex?

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

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

5. What is the purpose of this program?

6. When will this program finish executing?

My answers:

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

The above question isn't just about loading the malicious program into IDA and reading the code. Due to this fact, I'm going to analyze this malware "from scratch" without jumping directly into "Advanced Static Analysis". Firstly, let's open the file in Pestudio and check for useful information such as strings and imports. (since the malicious file is in the PE format this time)

The very first interesting information is the subsystem of this executable which is "console" so we now know that we have to use cmd to run this file properly.

Within the "indicators" section there is a hint about the URL saved inside the executable. This URL is "malwareanalysisbook.com" and can be treated as the network-based indicator of this malware.

From the list of the imports table I've decided to take these as the most attractive:

These imported functions tell us that this malicious program is probably a service:
- CreateServiceA
- OpenSCMangerA
- StartServiceCtrlDispatcherA

And these, in turn, give us information that this malware communicates with some host over the network:
- InternetOpenUrlA
- InternetOpenA

We have also some imports that do the job with threads, mutexes, and the heap. This program also probably loads some library in runtime due to these imported functions -> GetModuleFileNameA, GetProcAddress, LoadLibraryA. From the basic static analysis process, we can suppose that this malicious software also tries to get some information from the PEB memory section using these imports -> GetEnvironmentStrings, GetEnvironmentStringsW. In the further analysis process, we have to look for some command line indicators since the program imports GetCommandLineA function.

There is nothing hidden inside the resource section so we can jump directly into strings.

Obviously, there is the "malwareanalysisbook.com" URL in the strings section, although I mentioned it earlier. If the executable is a service indeed, then it should be the service name in the strings section and here it is -> MalService - this name is a well host-based indicator.

After basic static analysis, it's time for the basic static analysis process to check for the new processes created by the malware as well as called WinAPI functions. Obviously, I will be using Process Explorer, Process Monitor, Regshot, and fake network set between Windows XP and Linux machine.

First, I've taken the first snapshot using the Regshot tool to compare registry entries before the malware launch and after it. Wireshark's listening for the malware network actions.

As the subsystem suggests let's run this malicious program using the console.

After launching the malware it doesn't terminate but waits for something. To be able to answer the questions "What this file is waiting for?" we need to analyze the malware's code in IDA later on. The malware is running so let's take a second snapshot using Regshot and see if something has changed within the registry.

Now we can be sure that this malware is the service indeed with the name of "Malservice". When some file is a service then there are some useful information about it within the registry. To be able to query services we can use a builtin tool called sc. This is the console program responsible for querying and manipulating services on the Windows system. Let's use this tool to query the Malservice using the qc option.

Querying the service gives us the answer to the first question in this lab. This program ensures that it continues running when the computer is restarted by setting its START_TYPE to AUTO_START so this program starts at the boot time. It can set this value since the program is the service.

2) Why does this program use a mutex?

We have the question about the mutex of this program so let's see if it really sets some mutex using Process Explorer.

Unfortunately, there are many mutexes created by the malware so another way to investigate the correct mutex is to set the filter in the Process Monitor to Operation is OpenMutexA and another filter should be Operation is CreateMutexA.

Process Monitor didn't show anything related to the creation of the mutex. This behavior is suspicious, but we have one more option to make things right -> IDA. Let's get deep into the code of the malware and check for the function calls related to the mutexes.

This how the main function looks like. We already know from the basic static and dynamic analysis processes that the Lab07_01.exe creates service with the name of "MalService" which is started at the boot time of the system to achieve the persistence so we can safely jump into sub_401040.

The OpenMutexA function is called as the first WinAPI method inside our sub_401040 subroutine. If the function fails to open the "HGL345" mutex then the process executes this code primarily:

In other words -> if the mutex doesn't exist on the victim's machine then the program creates this "HGL345" mutex and achieving persistence as the service. Thus, this program uses a mutex to ensure that only one copy of the program is running at the time.

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

In the answer to the first question, I mentioned that the Lab07_01.exe achieves persistence by creating the "MalService" service with the START_TYPE: AUTO_START. Due to this fact, a good host-based signature to use for detecting this program is the MalService service running on the system started at the boot time. Obviously, another good host-based signature to use for detecting this program is the mutex named HGL345.

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

To gather some information about the network activity of the malware it's good to use some network sniffer. I've used Wireshark after setting everything up inside the fake network. I've also launched the ApateDNS to redirected every DNS response to the fake HTTP service running on my Linux machine. Let's see if ApateDNS and Wireshark caught something interesting.

ApateDNS gave us information about the domain requested by the malware. This domain is the "malwareanalysisbook.com" as we could expect based on the indicators gathered from the earlier analysis. Now let's see at the output of the Wireshark network sniffer. A couple of TCP requests and responses appear so to get a better view of the situation let's click Follow TCP Stream.

Now we know that the malware communicates with the "malwareanalysisbook.com" domain through the HTTP protocol. This communication, as well as the domain name, is a good network-based signature for detecting this malware. In the earlier process of the analysis, there was an "Internet Explorer 8.0" in the strings section of the executable. This exact string is used as the User-Agent for the malware connections and thus it's the next strong network-based indicator.

The above screenshots from IDA are the confirmation that the malware uses "Internet Explorer 8.0" User-Agent each time it connects to the specified domain.

5) What is the purpose of this program?

This program runs as a service called "MalService" to achieve persistence on the victim's system. Before installing as a service the malware opens a mutex called "HGL345" and checks if this exact mutex already exists on the OS. If "HGL345" exists the malware exits with 0 as error code. This means that the malware creates mutex to ensure that only one malware's executable is running at the time. After connecting with the Service Control Manager and the services database the binary installs itself as a service with the AUTO_START type. Thus, "MalService" starts each time the system boots. It appears that the next part of the execution measures the time it takes to create and execute threads inside the service:

SystemTimeToFileTime WinAPI function is called with the SystemTime structure as the first argument. The first element of the structure wYear is set to 2100 and the rest of the members are 0. This function converts the time saved inside the SystemTime structure to the FileTime which is the 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC). SetWaitableTimer activates our timer which is signaled after DueTime milliseconds elapsed. Then there is a call to WaitForSingleObject method with INFINITE value as the second argument and our timer as the first argument. This function checks for the object (in our case the timer) state and if it's not signaled the calling thread enters the wait state.

When the 2100 year will begin the malware will create exactly 20 threads. Threads are responsible for executing the code at the address passed to the CreateThread method as the third argument. Let's see what code each of the threads executes.

Each thread connects to the malwareanalysisbook.com using the Internet Explorer 8.0 User-Agent. It's worth to point that each thread establishes a connection with the domain inside the infinite loop. This action is called a DDoS.

When the OS scheduler decides to switch the context of the last thread created in the loop to the main thread, the malware sleeps for the 4294967295 milliseconds which is about 49 days.

Answer: The purpose of this malware is to do a DDoS attack on the malwareanalysisbook.com server.

6) When will this program finish executing?

This program will finish executing after about 49 days from the 1 January 2100. The whole analysis that leads to this answer is mentioned in the earlier question.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Lab 7-2
Analyze the malware found in the file Lab07-02.exe.

Questions:

1. How does this program achieve persistence?

2. What is the purpose of this program?

3. When will this program finish executing?

My answers:

1) How does this program achieve persistence?

Let's start the analysis process with basic static analysis using PeStudio tool.

The malware is a 32-bit PE file. To run this executable we need to use console since its subsystem is "console". The Imports Table is small because there are only 19 imported functions to this executable and therefore the further static analysis using IDA might be easy. The only useful string for us inside this malware is http://www.malwareanalysisbook.com/ad.html. ad.html file seems to be some kind of advertisement and thus we can assume that we are dealing with adware but to be 100% sure we have to analyze the code of the binary. Before this, let's analyze this file by using basic dynamic analysis techniques. (there aren't any resources in the binary so Resource Hacker tool will be useless this time) After launching the malware inside the console, the Internet Explorer appears with malwareanalysis.com/ad.html file displayed.

Obviously, the real ad.html doesn't look like the file displayed inside the browser from the screenshot since I'm using a fake network and also a fake HTTP server. Process Explorer tool has told us that the malware had exited immediately after the ad had appeared. Thus the malware doesn't achieve any persistence since it simply exits and the OS terminates this process.

2) What is the purpose of this program?

The purpose of this program is to display ad (explicitly) using Internet Explorer from the malwareanalysis.com domain, but we should see if this malware does something else implicitly.

Wireshark has confirmed that the malware had requested malwareanalysis.com/ad.html with the GET request. Regshot didn't show anything useful to us as well as Process Monitor - there were many WinAPI calls done by the malware but in my opinion, the best way to continue analysis and to find the answer to the question is to load the binary into IDA and see what is happening in more depth. First of all, it's worth looking at the Imports. The malware uses two meaningful functions from the analyst point of view - OleInitalize and CoCreateInstance. These two methods are here for COM object initialization and thus we can be sure that this suspicious file uses Component Object Model.

The Component Object Model is the way of re-using components and this technology is implemented as client and server model. A malware that uses COM may for example access Internet Explorer component to call the internal method. Internet Explorer component provides functionality for the specified COM interface and therefore, in this case, the Internet Explorer is the COM Class. In order to analyze a COM binary, a researcher must identify the COM Class to figure out what functionalities a binary might use. The knowledge about COM Interface (list of functions without the implementation) gives us the information which part of the COM Class a COM client uses. With this theory in mind let's get deeper into the malware's code.

Component Object Model feature from Windows OS is interesting, but also a little bit hard for me, therefore, I want to analyze the malware from scratch. Inside the main function Lab07-02.exe calls OleInitialize method to initialize the COM library. If all goes right then the malware makes use of CoCreateInstance function and the most important arguments passed to this function are riid and rclsid - Interface ID and Class ID respectively. Let's check this ID. After getting the CLSID we can search for the correct class in the Registry. Having an IID we can search for the correct interface on the Internet. The knowledge about the Class that provides the functionality of functions listed in the Interface is the key to understand the purpose of the malware that uses COM. IDA Free has the Hex View option which is good for reading exact bytes from the specified data. Click riid and View -> Open subviews -> Hex Dump. The riid value is marked. It's worth pointing out that the endianness on the x86 architecture is little-endian so the least significant bytes are first.

riid == D30C1661-CDAF-11D0-3E8A-6EE2C94FC0003E8A 

Simple pasting this value into Google gives as IWebBrowser2 interface as the result (https://docs.microsoft.com/en-us/dotnet/api/shdocvw.iwebbrowser2?view=dynamics-usd-3) So the COM interface used by the malware is IWebBrowser2.

Let's search the HKLM/SOFTWARE/Classes/CLSID for the rclsid.

Keeping in mind that the endianness is little-endian:

rclsid == 0002DF01-0000-0000-C000-0000000046 (after converting these bytes to the clsid value I got 0002DF01-0000-0000-00C0-000000000046 but the Class with such an ID doesn't exist inside Windows COMs)

Let's click the Ctrl + F inside the HKLM/SOFTWARE/Classes/CLSID and paste the correct Class ID to find the COM Class that provides the functionality to the malware. 

As you can see the malware uses the Internet Explorer COM Class to get the functionality for the functions listed inside the IWebBrowser2 interface.

The screenshot below shows the most important part of the malware's code:

Everything we have to do is to investigate what exact function from the IWebBrowser2 interface is called. The instruction responsible for this action is the last call obviously. The address of the function is taken from the structure. The base address of this structure is stored inside the edx register. Only two instructions are needed to tell what the structure really is. Here they are:

ppv is the address variable initialized by the earlier call to the CoCreateInstance. Inside the ppv there is the pointer to the COM object and this object is essentially a function pointers table. The functions referenced by that pointers are listed inside the specified COM Interface. It means that with the ppv variable initialized correctly, the malware can call the functions from the specified COM Interface. This behavior is illustrated in the above picture. The edx register stores the COM object address. (more precisely - the edx register stores the pointer to the function pointers table of the COM Interface) The malware use this address for calling the function from the Internet Explorer COM class. To find out what function from the COM class is called we have to search for the header file of the IWebBrowser2 interface. With this file in hand, we can check which function resides on the 0x2C offset. (obviously, this offset is relative to the beginning of the IWebBrowser2 interface structure within the header file) After typing "IWebBrowser2 interface structure header file" in Google I've found this article with the answer. ExDisp.h header file is the one we are looking for.

And this is the IWebBrowser2 interface structure:


Having offset, the position of the function can be calculated in this way: offset / 4 + 1. One has to be added since the first function in the structure has the offset 0. The position of the function used by the malware is 44 / 4 + 1 == 12. The twelfth function inside the IWebBrowser2 interface structure is Navigate. The purpose of this program is to display advertisement in the Internet Explorer window.

3) When will this program finish executing?

The program will finish executing when it fully displays the ad or when it fails to initialize the COM object.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

From now on I decided to analyze each lab thoroughly before answering the questions. I will answer the questions after ending of the analyzing process.

Analysis

Basic static analysis on Lab07-03.exe

I'll start with basic static analysis to find DLLs imported by the malware as well as the important strings.

Lab07-03.exe is the executable file with the console subsystem, obviously, it is also for x86 architecture. 

There are only two basic DLLs loaded by the malware's executable - kernel32.dll and msvcrt.dll. Lab07-03.dll isn't loaded by the malware's executable which is kinda suspicious.

The suspicious file has exactly six potentially dangerous functions marked as the blacklist. These methods are:

- UnmapViewOfFile

- MapViewOfFile

- CreateFileMappingA

- FindClose

- FindNextFileA

- FindFirstFileA

Another interesting functions are:

- CreateFileA

- CopyFileA

After looking at the imported functions we can infer that the malware can search for the specified file and loads this file into its own memory space to make some magic internally. It's worth pointing out that the malware can also destroy the whole system by jumping from one file to another and mixing them in an unpredictable way by using FindNextFileA, FindFirstFileA, CopyFileA, CreateFileA and all of the imported mapping functions.

The strings inside the executable are also interesting. 

The author of this malware has tried to outsmart victims by making "kerne132.dll" file very similar to the kernel32.dll provided by the Windows. "C:\*" string is common inside calls to FindNextFile and FindFirstFile functions. It's very likely that the malware makes action on ".exe" files on the C drive. .rsrc section is clear therefore it's time to use basic static analysis technique on Lab07-03.dll.

Basic static analysis of Lab07-03.dll

The malware's DLL imports exactly three DLLs that are responsible for providing appropriate functionalities for the malware's DLL exported functions. Apart from kernel32.dll and msvcrt.dll, there is a much more interesting DLL loaded called ws2_32.dll that provides networking functions to our malicious DLL.

The content of the Import Table indicates that this DLL might exports functions responsible for communication between malware and some server. Look at the networking functions imported by the DLL.

Obviously, we have to check this assumption by looking at the code using IDA but I would say that this DLL is used by the malware for communication with the C&C server. Apart from the network functions, there are also methods which are dealing with mutexes - CreateMutexA and OpenMutexA. I suppose that the malware uses this DLL also to ensure that only one instance of the malware executable is running at the time.

The string section has one string that is very meaningful in case of understanding how the malware works. After looking at the table I've found 127.26.152.13 which is the IP address of the local machine. (loopback) As the authors of the book mentioned - this address was changed by them to protect the malware analyst machines. This is the strong indicator that this DLL provides communication over the network functionality to the malware indeed.

Now it's time to do basic dynamic analysis on both malware files. The authors have written that this malware "may cause considerable damage"  to the analyst's machine, therefore, I'm going to take a snapshot before running it.

After taking a snapshot it's time to run the malware.

Basic dynamic analysis

This part of the analysis didn't tell us anything. The malware exits immediately after launching without leaving any footprint.

Advanced static analysis of Lab07-03.exe

A quick looking at the code is enough to point out why the malware exits immediately after launching. 

To run this malware properly we have to provide the argument while launching executable in cmd. Assuming that the binary was called with an argument, this branch is taken:

This part of malware's code is actually a loop where the first argument from the console is compared with the hard-coded string which is "WARNING_THIS_WILL_DESTROY_YOUR_MACHINE" in our case. Obviously, the real malware would have a simple command/switch like "-a" instead of warning, but authors of the book have changed this command to protect us from running this malware. If the argument is correct then eax stores 0 inside and serious malware's code finally starts. Before doing the below screenshot I used Symbolic constant option to simplify the analysis.

Starting from the top we have a call to the CreateFileA function. The malware opens the Kernel32.dll with GENERIC_READ access. The file handler resides inside the eax register after the function returns. The next WinAPI method used by the malware is CreateFileMappingA. This function creates a file mapping object in the current process memory space. A file mapping object can store any binary file. By calling the MapViewOfFile function the malware's behavior can be compared to the OS loader. As a result of these two careless calls, the malware loaded kernel32.dll file into its own address space. Next, Lab07-03.exe uses CreateFileA function again, but this time to read Lab07-03.dll which is used as the backdoor to ensure communication with the attacker's server.

The registry state after execution of the above malware's code:

eax -> handle to "Lab07-03.dll" file

esi -> handle to the file mapping object with "kernel32.dll" content written inside (with FILE_MAP_READ and PAGE_READONLY privileges)

I've cut the beginning of the if statement but you can believe me that this malware exits when the above CreateFileA function fails. Otherwise - if the malware owns the correct handle to the "Lab07-03.dll" file then another CreateFileMappingA is called along with MapViewOfFile. These WinAPI methods are responsible for writing the content of the "Lab07-03.dll" into malware's memory space with PAGE_READWRITE and FILE_MAP_ALL_ACCESS privileges. If one of these functions fails the malware exits.

The registry state after mapping DLLs into malware's memory space:

esi -> handle to the file mapping object with "kernel32.dll" content written inside (with FILE_MAP_READ and PAGE_READONLY privileges)

ebp -> handle to the file mapping object with "Lab07-03.dll" content written inside (with PAGE_READWRITE and FILE_MAP_ALL_ACCESS privileges)

[esp+<offset>+argv] -> handle to the file mapping object with "Lab07-03.dll" content written inside (with PAGE_READWRITE and FILE_MAP_ALL_ACCESS privileges)

Now we have to deal with quite a lot of code that modifies probably the content of the "Lab07-03.dll" with the help from "kernel32.dll" since file mapping object of the "kernel32.dll" file has FILE_MAP_READ and PAGE_READONLY privileges. What I learned from this book is that the very long and complicated functions might be writing by malware authors to confuse malware analysts. That being said I'm not going to analyze the code that affects file mappings line by line. Instead, I will look at this piece of code roughly.

The first lines of code are clear enough to tell that the malware uses kernel32.dll file mapping as well as Lab07-03.dll file mapping. To deal with the contents of these two the malware calls sub_401040 function with 3 arguments. These arguments are the addresses of some locations within the PE format. Let's jump to this function and see what is going on inside with these addresses.

These addresses are passed to the next function named sub_401000 by the IDA. After the function has done its job the malware does some arithmetic without writing anything into memory. We now know that the sub_401040 returns something - it might be the pointer to some structure inside the PE file format but this is only an assumption. sub_401000 also does some operations on the file mapping object but it's not important for us at this moment. 

These marked instructions are called to scan the part of file mapping objects memory (in case of scasb) and for writing bytes or words inside file mapping objects memory. (in case of movsb and moved respectively) As we already know from earlier analysis process, kernel32.dll file mapping object has only PAGE_READONLY and FILE_MAP_READ privileges, therefore, I'm pretty sure that the malware tries to modify Lab07-03.dll (with writing privileges) with some data gathered from kernel32.dll and this is done by "rep movsb" or "rep movsd" instructions. Memory modifications are made inside the loop. Let's say that the malware has done everything related to DLLs modifications. Here is the code that will be executed:

At first glance, you can see that this code loads Lab07-03.dll as kerne132.dll inside every process on the disk C. I guess that the kerne132.dll is run in place of the kernel32.dll. Let's try to confirm my assumption and jump right into sub_4011E0 subroutine since earlier calls are clean and simple. 

The last subroutine called inside the main function consists of calls to "Find Files" functions from WinAPI. The argument passed to this subroutine is "C:\\*", therefore, the malware probably tries to access some files inside the whole C drive. My assumption is based on the above-mentioned calls and the loop which ends when FindNextFileA fails.

At the beginning of the loop, we have a call to malloc which obviously allocates some memory on the heap. I don't know how many bytes this exact call to malloc allocates but I would check this with the debugger, unfortunately, I can't do this for now on.

Along with the mentioned call, the malware uses some repne scasb and rep movs instructions which are basically strlen and memcpy respectively. The important fact is that the ".exe" string is pushed on the stack thus we can suppose that this malware does kernel32.dll to kerne132.dll swap only for executable files. 

After some memory operations with arithmetic tricks on the found file, there is a call to the _stricmp function. This method is the alias for the POSIX stricmp function and does the same thing. That being said according to stricmp_wiki this function should have exactly two arguments passed to it using a stack. 

 

The marked instructions are used for pass the arguments to the later _stricmp call. Arithmetic operation done on the ebx register is a little bit complicated and IDA didn't give us any hint what the first argument really is. Again, I would use a debugger to investigate ebx register value before pushing it on the stack, but I can't use a debugger in this Lab. My next guess is that we have the extension of the found file inside the ebx. So the _stricmp call probably looks like this -> _stricmp(found_file_extension, ".exe");. 

Next, we have an if statement which gives us a meaningful hint on how the _stricmp is called.

If the extension of the found file is ".exe" then _stricmp returns 0 and the malware calls sub_4010A0 subroutine. Otherwise, the malware tries to find the next file on the specified drive. Therefore, I'm almost sure now that this malicious program searches for the executable files with ".exe" extension and deals only with them. Let's check the internals of sub_4010A0.

The first part of the subroutine maps a found file into the current process memory with PAGE_READWRITE and FILE_MAP_ALL_ACCESS privileges. 

Then the malware does some operations inside a found file if a taken pointer to some internal structure is correct - that's why there are calls to the IsBadReadPtr WinAPI function. operations_on_mem function was called inside the main function, but this time after the rough analysis process I changed the name to something more understandable. Let's see what happens next as this is pretty interesting to us.

The value of the ebx register passed as the first argument to the _stricmp function is probably a pointer to the name of the loaded DLL by the found file. This loaded DLL has to be special - it has to be "kernel32.dll". If the "kernel32.dll" is loaded by the found file, then the malware changes the name of the loaded DLL from "kernel32.dll" to "kerne132.dll" inside found file! As you can see we finally know what is the purpose of the malware's executable. But before starting malware's DLL analysis we need to jump into the program branch that we avoided earlier to see if the malicious program does something wrong there.

The most important part of the branch is here:

The marked code is actually a recursive call. It means that the malware searches the whole file system for .exe files instead of looking into C drive only. This is only an assumption, that being said we should analyze the malware with dynamic analysis using Procmon for example to be sure that this malicious program searches the whole file-system for .exe files indeed. We finally reach the end of the malware's exe analysis and now it's time to summarize the whole investigation.

 To sum up: The first thing that the malware does is checking for the appropriate argument passed to it using the console. If the argument is "WARNING_THIS_WILL_DESTROY_YOUR_MACHINE" then the malware launches. Next, we have some operations done on kernel32.dll and Lab07-03.dll. More precisely, the malware probably creates forward exports from kernel32.dll to Lab07-03.dll. After these complex memory actions the Lab07-03.dll should have the same exported functions as the kernel32.dll - it will guarantee that the infected files will run on the system without any locks since they will import methods from kernel32.dll using malicious Lab07-03.dll. To outsmart the victim the malicious program changes kernel32.dll string to kerne132.dll after changing the Lab07-03.dll filename to kerne132.dll. 

The malware probably performs the substitution kernel32.dll to kerne132.dll on each .exe file on the system. To confirm this assumption we should do a basic dynamic analysis and investigate changes within the file-system.

One more thing: What the malware does is commonly known as DLL injection. It performs this attack unnoticed since the infected executables can import the kernel32.dll methods from the malicious DLL due to forwarded exports. The dangerous operation is done inside the DllMain of the malware's DLL since the code from this function is executed after loading malicious DLL into an infected executable address space.

Now it's time to analyze the malicious DLL.

Advanced static analysis of Lab07-03.dll

From the earlier static analysis, we know that this DLL is used for some networking communication. We also know that the malware's executable is used as injector in the DLL injection attack. That being said this DLL is responsible for doing "bad things" on the victim's machine. We have to remember that this DLL is most likely injected into every single ".exe" on the system. Let's see what we have inside.

This is the beginning of the DllMain:

First, the DLL checks if it's loaded into the process memory by comparing fdwReason parameter with DLL_PROCESS_ATTACH. If fdwReason isn't DLL_PROCESS_ATTACH then the malware doesn't infect found executable since the code from DllMain isn't executed. Let's suppose that this malicious DLL was attached to the process memory by LoadLibrary function or just by running this process - in this situation the malware gets fully executed and we have to analyze this part of code:

As you can see the above code is known in the malware analysts environment since the first part of this code does something like memset(buf, 0, 1023), and then it checks if the SADFHUHF mutex exists. If this check is true then the malware exits, if the mutex doesn't exist then the malicious program creates it. This operation is done to ensure that only one instance of the malware is running at the time. Next, we have a call to the WSAStartup function which initializes the WinSock structure - this method is also used for making certain that Winsock is supported on the system. If the system doesn't support ws2_32.dll (Winsock) then the malware exits after WSAStartup failure. Otherwise, it executes this block of instructions:

The malware creates a TCP socket and exits if a socket can't be created. If the socket already exists then it initializes sockaddr structure with the family of IP addresses used in communication, port which is set to 80 and IP which is set to 127.26.152.13. Thus, the infected executable tries to connect (using call to the connect with sockaddr structure initialized obviously) to the host with 127.26.152.13 IP address on port 80 which indicates communication using HTTP protocol. 

After a successful connection with the attacker's server, the malware sends a "hello" string to inform an attacker that another machine is infected. A smart call to the shutdown method imported from Winsock blocks a sending option on the created socket, after this part of code the malware can't send anything to the server. 

It's impossible for malware to send data to the server but the socket can receive data from the server indeed. That's what our malicious program does - it waits for the commands from the C&C master. Everything that I've mentioned from sending "hello" string to receiving commands happens inside the loop. This means that the malware sends a "hello" string to inform C&C master that "a machine is infected and I'm ready to talk with you".  But I have to tell you that I'm a bit confused since after the call to the recv method the socket isn't unblocked for sending, so how the malware can send "hello" through the blocked socket? Anyway, if the malware finally receives some data it executes this code:

Obviously, the "data" received by the malware has to be some kind of command. From looking at the code it's clear that the commands handled by the malware are "sleep" and "exec". 

Description of the commands executed by the malicious software:

- sleep -> when the attacker sends this command to the infected machine, the malware sleeps for 393216 milliseconds -> 393,216 seconds -> approximately 6 minutes.

- exec -> investigating this command requires more effort. We have to analyze this piece of code:

The first three lines of code are exactly like memset(STARTUPINFO, 0, sizeof(STARTUPINFO));, STARTUPINFO is a structure that describes processes on Windows -> https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-startupinfoa.  As the name suggests, CreateProcessA function creates a process on Windows systems based on the lpApplicationName parameter. If this parameter is NULL then the process name is the first white-space delimited string from lpCommandLine argument. This means that if we want to understand how the malware responses to "exec" command we need to check the content of lpCommandLine.

CommandLine variable isn't initialized earlier, instead, it's a part of the buf buffer which stores data sent by the C&C master. Let's have a look:

This picture is very useful for us since it explains everything that we want to know for now. The first five bytes of the buffer are most likely for "exec " string and the rest of the buffer is for storing the process name to run. Thus, the real command is "exec <process to run on the victim's system>" and obviously it's responsible for executing any program the attacker want. 

And there is one more command that the malware handles -> q.

If the malware receives "q" as the command it closes all handles and returns from the DllMain which is equal to exit in this case. Otherwise - if the command isn't "sleep", "exec <file>" or "q" the malware sleeps for approximately 6 minutes. 

It's worth pointing out that the whole communication scheme is done inside the loop and after each successful run of the command the malware informs C&C master about it by sending "hello". So as I mentioned earlier - "hello" means "I'm ready to execute the command".

And that's all, now we can answer the questions but before that let's check our assumption that the malware's executable really injects kerne132.dll inside each executable on the system. This check can be done using a basic dynamic analysis tool called Procmon.

Basic dynamic analysis (again)

Now we know that to execute the malware the correct argument has to be passed - "WARNING_THIS_WILL_DESTROY_YOUR_MACHINE". Before launching the malicious program I'm going to take a snapshot. After taking a snapshot, let's set the appropriate filters such as Process Name -> is -> Lab07-03.exe, Operation -> is -> CreateFileMapping and run Procmon. Alongside with Procmon, it's useful to use Process Explorer since with this tool we can check the modules loaded by the executables.

Procmon gave us information that the malware's injector modifies each "exe" file on the system:

Now it's time to check for the DLLs loaded by any of the executable using Process Explorer. Let's open Mozilla Firefox for example.

As you can see the malicious DLL is loaded by the firefox.exe and this DLL will be loaded by any executable that we will execute after infection. Now our system is infected and the machine waits for the commands from C&C master. The next thing to do is to compare Lab07-03.dll with kerne132.dll and to do this we have to compare the hashes of the DLLs. Let's use WinMD5 tool for this:

This is the final confirmation that the kerne132.dll is the same as the malicious Lab07-03.dll. The analysis process of the malware is officially over. :) Let's answer the questions.

My answers:

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

This program uses DLL injection to ensure that it continues running when the computer is restarted. The malware's executable substitutes original kernel32.dll with the fake one named kerne132.dll. This fake DLL is actually a backdoor and it's injected into each executable on the system - that's why this program will keep running even if the computer is restarted.

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

The very first host-based indicator is obviously the existence of C:\Windows\system32\kerne132.dll that is injected into each executable on the system. The second host-based indicator is a mutex named SADFHUHF.

3) What is the purpose of this program?

This program acts as a backdoor with three commands available to the C&C master. The malware can sleep for approximately 6 minutes if the sent command is "sleep" or if the sent command isn't available. The malicious program can also execute any program on the system (if the program has appropriate privileges) using "exec" command. The last command is "q" which is responsible for turning off the backdoor but it's important to mention that if a victim launches new executable then the malware wakes up again.

4) How could you remove this malware once it is installed?

This malware was created with making removing hard for a victim in mind. Thus, it's not an easy task. Restoring a backup is always a good idea after infection and in this situation, a backup would help too. Another way to remove the malware is to create PE program which would be responsible for substituting kerne132.dll with original kernel32.dll in each executable on the system - it would reverse everything that the malware did. The last thing to do is to install OS once again since the malware doesn't reside inside the bootloader for example.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Lab07 was definitely the most challenging but also worthy. The analysis of Lab07-03 which was real-word malware was fascinating for me and I think that I'm ready to continue my learning process. I felt progress after solving the above challenges and I'm looking forward to the next malware analysis labs. Thanks for reading and see you soon. :) Cheers!