In this article, I will show how to use the INetSim utility to emulate the interaction of malware with a control server. We will also consider the work of the loader, unpack the main payload of the malware and examine the stealer's operation scheme.

We will analyze the UnPackMe Blue Team Lab task from the Cyber ​​Defenders platform. The task level is difficult. In the lab work, you will need to answer a number of questions based on the results of the completion, but we will not provide the answers - if you repeat the completion, you will easily answer everything yourself.
 Utilities Used

1. DIE is a program for identifying file types.
   
2. PeStudio is a program for searching for artifacts of executable files.
   
3. IDA Pro is an interactive disassembler used for reverse engineering.
   
4. Wireshark is a tool for analyzing network traffic.
   
5. Burp Suite is a platform that is used as a transparent proxy server to analyze the interaction of a malicious file over HTTPS.
   
6. x64dbg is an open source debugger for Windows designed for malware analysis.
   
7. INetSim is an Internet emulator.
   

 Primary analysisLet's get some initial information about the sample being studied. Load the file into DIE and select the Nauz File Detector analyzer.

The sample under study is assembled for 32-bit systems, developed in C/C++ and compiled in Microsoft Visual Studio. Let's get the entropy of the executable file by sections. Let's go to the Entropy tab and determine its value.

The entropy of the file under study is 7.389, with the highest value in the .text section. This means that the file under study is packed.
 Exploring the bootloaderLet's load the file into IDA and start analyzing. The entry point points to the WinMain function, and the main execution flow is implemented in the sub_468480 function.


Let's go to this function by double-clicking and decompile it by pressing F5.

The WrapGlobalAlloc function implements the GlobalAlloc address and allocation of memory in the heap equal to the length of the shellcode. Then, in the WrapVirtualProtect function, the allocated memory area is assigned execution, reading, and writing rights (PAGE_EXECUTE_READWRITE) using the VirtualProtect function . The next step is the shellcode decryption process.

Encryption consists of key conversion and the XOR operation.


The initial key value is 0xD5AF2F45. To decrypt the shellcode, we will develop a script for IDA, to the input of which we will pass the address of the encrypted shellcode, its size, the initial key value, and the name of the file for saving the data.

We will decrypt in debug mode. Set a breakpoint on the WrapDecryptShellcode function (hotkey F2) and start debugging (F9). Double-click on the shellcode variable to get the address of the executable code, and its size is found out from the size_shellcode variable.

Load the developed script, for this, go to the File → Script File tab. In the Python command line, call the main function.
 

We have obtained the value of the decrypted executable code. Let's load it into IDA and perform static analysis. The resulting shell code consists of functions for obtaining the addresses of the WinAPIs used and decrypting the main payload.


Let's transform the decompiled code into a readable form. To do this, select the variable a1, right-click and select Create Struct. IDA will generate the structure. Next, rename each field value (hotkey N). Hashing is used to obtain the WinAPI LoadLibraryA and GetProcAddress

functions from the kernel32.dll library. The names of dynamic libraries are read from the InMemoryOrderModuleList field of the PEB structure of the process. The hash value is calculated from each name and compared with the value 0xd4e88. The same procedure is performed with the names of the export functions of the found dynamic library. The hashing algorithm is presented below.



The value 0xd4e88 corresponds to kernel32.dll.



The process of obtaining the main load consists of the stages of decryption and unarchiving.



The decryption algorithm is the same, but the decompression algorithm is heavily obfuscated and contains many transitions (goto). Let's unpack our payload. To do this, in debug mode, go to the shellcode execution and find the DecryptUnpackShellcode function. Next, go down to the Unpack function execution, go to the Hex View tab (press G) and enter the address stored in the data variable. We get the size from the value of the unpack_size variable.

We dump the shellcode obtained after unpacking using the IDA API. To do this, go to the Python command shell and enter the following command:



We have received the main payload, it is a shell code, the task of which is to load an executable file using the Process Hollowing method and start execution from its entry point. Let's load the received file into a Hex editor, copy the data starting with the MZ signature, and start analyzing it.



At this stage, you and I have unpacked the main payload, which is an executable file. The loader's work is divided into several stages: first, the executable code is decrypted, the main task of which is to decrypt and unpack the shell code of the next stage. The shell code of the next stage loads the executable file into memory and continues execution from its entry point.


 Let's explore the main loadLet's get information about the executable file by loading it into the DIE utility.



The main payload is developed in C/C++, compiled in Microsoft Visual Studio and built for 32-bit systems. Let's load the file into IDA and start static analysis. The malware code is heavily obfuscated and the execution flow graph is very large.



All strings used during the module's operation are encrypted using XOR with a one-byte key. Let's sketch out a script for IDA that will decrypt the strings.



In the first step, the module checks whether an instance is running in the system using the OpenMutexA function .



In the Python command line, run the function to decode the mutex name:


The mutex name is formed from the constant value uiabfqwfu, added to the user name. If a mutex with such a name exists, the module stops working.
Then the module uses the GetLocaleInfoA function to find out what languages ​​are installed in the system. If a language from a certain list is present (Russian is included), the module stops working.


Next, the process of interaction with the control server begins. The C2 server address is encrypted with the RC4 algorithm and encoded in Base64.



Let's decrypt the key stored in the RC4_KEY variable. 

The encryption key is $Z2s'ten\@bE9vzR for the RC4 algorithm.
Let's decrypt the control server address using the CyberChef utility.



We received the address of the control server: 
 Interaction with the control serverWhen accessing the control server https://tttttt.me/ch0koalpengold, the sample under study receives the address of the main C2 server. The address is located in a div block containing the following attributes.



The main address of the control server is encrypted with the RC4 algorithm. Key:




When accessing the main address of the control server, the sample under study receives a config encrypted with the RC4 algorithm with the key $Z2s'ten\@bE9vzR.
Let's proceed to configuring INetSim. Open the sample.html file using this path:



And add a div block with the attributes listed above. The value gzWH3jR7snsUFO5aZbvXyda3vfp8cjiuis encrypted using the RC4 algorithm with the key 6af7fae138b9752d1d76736dcb534c9d. The encrypted string has characters added that are removed during the decryption process.



In the directory, /var/lib/inetsim/http/fakefileswe will create a config.json file containing encrypted settings.





This config is obtained as a result of static code analysis and is needed for the sample to work. The au parameter contains the URL for loading the sqlite3.dll library, the ip and location parameters contain information about the network address of the infected machine, the is_screen_enabled parameter is needed to get a screenshot of the desktop, and the rm parameter is needed in case you need to delete yourself after collecting information.
We will also load the sqlite3.dll file into the /var/lib/inetsim/http/fakefiles directory.
In the file, we will add static URLs /etc/inetsim/inetsim.confin the block .https_static_fakefile



Each time the malware accesses addresses with the /config/ substring, the config.json file (module configuration) is loaded, and when /config/files/ is opened, the sqlite3.dll library is loaded.
Let's restart the INetSim utility.



Let's start dynamic analysis of the sample under study. When dynamically debugging, do not forget to bypass the language standard check if your virtual machine has Russian language installed.
Having received the main address of the control server, the malicious file begins to establish its first connection.



The values ​​in the POST request are formed as follows: 

The b parameter describes the infected machine identifier, which is formed from the system user name and the MachineGuid registry key value: 

The c parameter specifies a constant value. The generated string is encrypted using the RC4 algorithm with the key $Z2s'ten\@bE9vzR. The module configuration comes in response from the control server.
To operate the browser data collection function, the malware requires the dynamic library sqlite3.dll. The au parameter in the config specifies the URL by which the malware can obtain this library.


 Collecting information about the systemWorking directory of the malicious file:



Additional modules and collected files from the system are loaded into this directory.
The collection function is located at offset 454A (in my case, the function is sub_56454A), to go to the code, you need to enter the offset value in the Function tab. At the stage of collecting system data, the sample under study generates the System Info.txt file in the working directory.



Contents of the System Info.txt file:

• The string Raccoon | 1.7.3 describes the version of the malicious file, this value is encrypted with the string encryption algorithm.
  
• Build compile date is set as a constant and indicates the date the file was compiled.
  
• Launched at contains the date and time of the launch.
  
• The System Information block contains information about the host name, time zone, language installed in the system, processor, amount of RAM and displays.
  
• The Installed Apps block contains information about installed applications; this list is obtained from the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
  

If the config received from the control server contains the value is_screen_enabled:1, a screenshot of the user's desktop is taken. The screenshot creation function is located at offset 951B.



After screen capture, the bitmap image is saved to the working directory with the name screen.jpeg.
After all the information is collected from the host, a ZIP archive is created in the working directory. The file name is taken from the _id parameter in the config received from C2.





If the rm parameter value is "true", the malicious file starts the process of self-deletion. The deletion function is located at offset 5D47.



The cmd variable forms a command to remove traces of malware presence in the system. Let's decipher the value.



This is what happened: 

Also, during the initial analysis of the executable file, I found the full path to the assembly directory on the attacker's computer: 
 Conclusions
This lab helped us learn how to emulate the operation of a control server using the INetSim utility. We analyzed the mechanism of the stealer, whose task was to steal crypto wallets, cookies, passwords from browsers and mail servers, and much more. We studied the operation of the loader and unpacked the main load, and also wrote scripts for IDA and practiced static and dynamic analysis of malicious files.