Koi Loader/Stealer - Part 1
On January 12, 2024, Cyble released a report titled "Sneaky Azorult Back in Action and Goes Undetected," highlighting key indicators of a concerning resurgence. Subsequent analysis by InfoSec experts revealed that this malware constituted a wholly new variant, devoid of any code overlap with previous Azorult iterations.
The Koi Loader campaign orchestrates a multi-stage infection chain culminating in the dissemination of the Koi Stealer malware.
A "loader" is a type of malicious software designed to facilitate the delivery and execution of additional malware payloads onto a victim's system. Its primary function is to initiate the infection process by downloading and installing further malicious components, often operating stealthily to evade detection and to maintain persistence within the compromised system.
On the other hand, a "stealer" malware, such as the Koi Stealer in this context, specializes in clandestinely extracting sensitive information from infected devices. Typically, this includes credentials, financial data, and other personally identifiable information, which is then exfiltrated to remote servers controlled by malicious actors. Stealers are engineered to operate covertly, aiming to evade detection by security measures while surreptitiously harvesting valuable data from compromised systems.
The current Koi Loader/Koi Stealer campaigns are incorporating bank statement-themed lures, as indicated by the findings outlined in the Cyble report and the information discussed on this platform.
Before discussing the intricacies of the analysis, let us first examine an overview of the infection chain.
Figure 1: Illustrates the infection chain of the Koi Loader/Koi Stealer campaign.
Despite the initial challenge in obtaining the initial email, Brad (@malware_traffic) successfully acquired the redirection link presented to the user to download the malicious statement. Additionally, he meticulously documented the step-by-step process of the infected ZIP download from the perspective of an unsuspecting user as shown below.
Figure 2: Brad's depiction of the step-by-step process of the infected ZIP download from the perspective of an unsuspecting user
Lastly, before delving into the analysis, it is important to acknowledge the contribution of Unit 42 (@Unit42_Intel), who was the first to attribute this malware as Koi Loader/Koi Stealer in their X post.
In this article, we will analyze a file similar to the one observed by Brad, titled 'chasebank_statement_mar.zip'.
Figure 3: Illustrates the malicious ZIP file, disguised as a Chase Bank statement
Upon extraction, an LNK file impersonating a PDF document is observed, with the icon resembling that of a PDF document.
Figure 4: Depicts the LNK file impersonating a PDF document
Upon viewing the file properties, we are able to see the file command line.
Figure 5: Illustrates the malicious command line associated with the LNK file
The associated command line with the LNK file is as follows:
The provided command line indicates that upon execution, the file downloads a malicious BAT file to the temporary directory and establishes a scheduled task to execute it every minute.
Figure 6: Depicts the downloaded malicious BAT file
Upon inspecting the contents of the BAT file, it becomes apparent that it contains Powershell commands to download a malicious JS file to the temporary directory, delete the previously created scheduled task by the LNK file, and execute the malicious JS file using wscript.exe.
Figure 7: Illustrates the batch script contained within the malicious BAT file
For reference, the contents of the malicious batch script are as follows:
Figure 8: Depicts the downloaded malicious JS file
Upon inspecting the downloaded JS file, a lightly obfuscated script is observed.
Figure 9: Illustrates the obfuscated contents of the JS file
For reference, the contents of the malicious JS file are as follows:
The unobfuscated script is as follows:
The malicious code provided above is responsible for initializing instances of FileSystemObject and WScript.Shell, determining the system's architecture and constructing the path to PowerShell executable accordingly. It then attempts to copy itself to a new location for persistence, excluding the scenario where the script name is agent.js. Subsequently, it defines a mutex name and tries to delete a mutex file. The core functionality lies in executing PowerShell commands: it sets an environment variable, downloads and executes two PowerShell scripts (agent1.ps1 and agent3.ps1) from remote URLs. This action occurs only if the mutex file does not exist.
Figure 10: Illustrates the downloaded malicious PowerShell scripts
The agent1.ps1 PowerShell script retrieves all types from the currently loaded assembly and searches for a specific type with a name containing "iUtils". Once this type is found, it proceeds to retrieve all non-public and static fields within it. Subsequently, it searches for a field within this type with a name containing "ailed".
The script likely targets AmsiUtils, indicated by the naming convention used to search for types containing "iUtils" and fields containing "ailed." In particular, the $f.SetValue($null,$true) command observed in the previous JS script sets the value of amsiInitFailed to true. This action effectively bypasses AMSI, a critical security feature in PowerShell, enabling malicious scripts to evade detection and execute without interference from AMSI's scanning mechanisms. By circumventing AMSI, the script can proceed with executing potentially harmful commands or payloads without being detected, posing significant security risks to the system.
Figure 11: Illustrates the script contained within agent1.ps1
For reference, the contents of the malicious agent1.ps1 file are as follows:
After making modifications to the code and executing it, we obtain the targeted items. The modified code is as follows:
Figure 12: Displays the values of variables $c and $f as set by agent1.ps1
The agent3.ps1 Powershell script initializes shellcode ($sc) and retrieves the addresses of essential Win32 API functions like VirtualAlloc, CreateThread, and WaitForSingleObject. Subsequently, it allocates memory within the current process's address space using VirtualAlloc and copies the shellcode into this allocated memory. It creates a thread in the current process's context using CreateThread, passing the shellcode's start address as the thread's entry point and the remote executable's image buffer as a variable to be passed to the thread. Finally, it waits indefinitely for the thread to terminate using WaitForSingleObject.
Figure 13: Illustrates the script contained within agent3.ps1
For reference, the contents of the malicious agent3.ps1 file are as follows:
Before analyzing the remote .exe file, let's first examine the shellcode. The shellcode facilitates the loading and mapping of the remote Portable Executable (PE) image into memory by executing precise instructions to initialize the runtime environment and prepare the necessary resources. This procedure can be regarded as a form of obfuscation, as our observation indicates that the PE file executes seamlessly without requiring additional intervention from external sources.
Static analysis presents one avenue for examining the shellcode's behavior. However, its scope is limited, offering only a partial understanding of its intricacies.
Figure 14: Depicts an endeavor to analyze the shellcode statically
However, dynamic analysis has proven more fruitful in understanding the shellcode's behavior. Traditional shellcode execution tools lack the capability to pass required arguments, prompting us to develop the following barebones C program to execute the shellcode with the required arguments and analyze the shellcode effectively.
Executing the provided code enables us to set breakpoints following the second VirtualAlloc call, which facilitates the debugging of the shellcode during execution. Importantly, the correct arguments are passed to recreate its intended behavior, enhancing the accuracy of our analysis. We arrived at the previously mentioned analysis of the shellcode by employing this process, which serves as the foundation for our understanding of the shellcode behavior.
Finally, let's delve into comprehending the functionality of the remote executable referenced in agent3.ps1.
Figure 15: Displays the remote executable referenced in agent3.ps1
Upon analysis, it's observed that this executable file functions as a loader tasked with extracting a block of data sized at 0x9c00 from alternate bytes within the .rsrc section of the PE file. Subsequently, it applies an XOR operation with the key specified immediately before the aforementioned data within the .rsrc section.
Figure 16: On the left, the decryption function is highlighted, while on the right, the XOR key is highlighted
Figure 17: On the left, the decryption function is highlighted, while on the right, the starting point of the encrypted data is highlighted
After reading alternate bytes from the beginning of the encrypted data section and decrypting it using the XOR key, the file proceeds to map the resulting decrypted PE file in memory for execution.
I have written a Python script to statically dump the decrypted PE file using the analysis points mentioned. This script also prints out URLs observed as strings from the dumped PE file.
This resultant dumped PE file is clean and can be analyzed easily due to minimal obfuscation and the presence of strings in cleartext.
Figure 18: Demonstrates the execution of the Python script against the sample, resulting in the dumping of a clean PE file along with the printed URLs found within this file
Figure 19: Displays the clean PE output generated from the execution of the Python script against the loader binary
Upon analyzing the decrypted PE file, we observe the presence of two additional payloads that are referenced and utilized by the malware.
Figure 20: Displays the download script of two additional payloads, namely sd4.ps1 and sd2.ps1 orchestrated by a PowerShell script
Figure 21: Illustrates the two final payloads utilized by the malware
These PowerShell scripts are responsible loading two .NET executables into memory. However, this blog post primarily emphasizes the initial delivery and loading mechanisms employed by the malware, rather than delving into its complete functionality. The next installment will provide a comprehensive analysis of the malware's behavior and features, including these scripts.
IOCs
The indicators mentioned here are based on the analysis conducted by me and do not include any externally referenced indicators.