eSentire is The Authority in Managed Detection and Response Services, protecting the critical data and applications of 2000+ organizations in 80+ countries from known and unknown cyber threats. Founded in 2001, the company’s mission is to hunt, investigate and stop cyber threats before they become business disrupting events.
We provide sophisticated cybersecurity solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs). Find out why you should partner with eSentire, the Authority in Managed Detection and Response, today.
Adversaries don’t work 9-5 and neither do we. At eSentire, our 24/7 SOCs are staffed with Elite Threat Hunters and Cyber Analysts who hunt, investigate, contain and respond to threats within minutes.
We have discovered some of the most dangerous threats and nation state attacks in our space – including the Kaseya MSP breach and the more_eggs malware.
Our Security Operations Centers are supported with Threat Intelligence, Tactical Threat Response and Advanced Threat Analytics driven by our Threat Response Unit – the TRU team.
In TRU Positives, eSentire’s Threat Response Unit (TRU) provides a summary of a recent threat investigation. We outline how we responded to the confirmed threat and what recommendations we have going forward.
Here’s the latest from our TRU Team…
What did we find?
At the end of March 2024, the eSentire Threat Response Unit (TRU) detected an infection by the stealer malware allegedly being tracked by some researchers as AZORult.
AZORult is an infostealer malware first discovered in 2016. AZORult's sales stopped at the end of 2018 and the seller announced the end of the project, which translates from Russian to English: "Every piece of software has its lifespan. And for AZORult, it has come to an end. With both sadness and joy, I announce that sales are closed forever"
(Figure 1).
Figure 1: CrydBrox announcement on closing the AZORult sales
In early 2019, Kaspersky unveiled
details indicating that AZORult had been rewritten from Delphi to C++. Fast-forward to the beginning of 2024, Cyble
and Netskope
have reported on yet another resurgence of AZORult, but this time with the code switched to .NET. However, a detailed comparison of Netskope’s, Cyble's, and Kaspersky's samples showed no code overlaps.
A Threat Researcher, Ernesto Fernández from Trellix, highlighted an article
that identifies the malware as Koi Loader and Koi Stealer, reflecting the analyses by Cyble and Netskope. These findings including the Twitter post from Unit42 and some discussions with Principle Threat Researcher at Palo Alto have led us to adopt the terms Koi Loader and Koi Stealer for this article's discussion.
Initial Infection
The user received a phishing email about an unauthorized transaction on the sender's debit card containing an embedded link (Figure 2). This link directed the user to download a malicious ZIP archive named “chasebank_statement_mar.zip” (MD5: 8751223ced55a2079e876b893917a0f3). Notably, the file hashes of the archive change with each new download.
Figure 2: Phishing email
As seen in Figure 3, we found multiple reports on the sender’s email on spam[.]org with email subject lines such as:
Concerned about an ambiguous charge on my bank statement - seeking your help
Need your guidance with a puzzling payment on my credit card - could you advise
Uneasy about an unknown charge on my bank statement connected to your store - could you assist
Unforeseen payment on my debit card linked to your website - looking for your guidance
Concerned about an unforeseen charge on my account - appreciate your assistance
Figure 3: Complaint report on spam[.]org
Upon visiting the embedded malicious page that is hosted on Google Sites, we received a CAPTCHA prompt (Figure 4).
Figure 4: CAPTCHA page on Google Sites
It’s worth noting that to receive the payload, the user would have to pass the CAPTCHA prompt first. If the user fails the CAPTCHA prompt, the server will respond with “NO” status (Figure 5).
Figure 5: Response from the server if the CAPTCHA prompt fails
If the user passes the CAPTCHA prompt, the server responds with “YES” status and serves the ZIP archive.
Figure 6: Response from the server if the CAPTCHA prompt is passed
The ZIP archive includes a shortcut file (.lnk) named “chasebank_statement_mar.lnk” (MD5: 044fd3c4d97a35f80792b7edee445c48), which downloads the next stage payload from the server, “m8hHxtkVLYPw.bat” (MD5: 099259c6d898c5d91dc3b01756e349d8), using curl.
This file is then stored in the %TEMP% folder. Additionally, it establishes persistence on the system by creating a Scheduled Task named “0BAduEnQZG9POyK”. (Figure 7).
Figure 7: Contents of the shortcut file
Koi payloads are usually all placed within the same opendir link, as shown in Figure 8.
Figure 8: Example of the opendir hosting Koi payloads
The download batch file “m8hHxtkVLYPw.bat” contains the PowerShell command (Figure 9) that is responsible for fetching another payload from the server “WLXUL6LWXQPB.js” (MD5: 48c7fd278ac590c9bd896ad9c7850c3a).
Figure 9: Contents of the batch script
The downloaded JavaScript file is responsible for self-replication, the script checks if its current filename is agent.js. If not, it attempts to copy itself to the %programdata% directory with the filename agent.js. It defines a mutex name “7z2LKLJ62LPA” and attempts to delete any file with that name in the %temp% directory. If a file with the mutex name does not exist (indicating that another instance may not be running), it proceeds to retrieve and execute additional payloads via PowerShell commands, as shown in Figure 10.
Figure 10: Contents of the JavaScript file
The PowerShell script agent1.ps1 (MD5: 96b251e61f987648f69767f398324652) contains a one-liner command that is responsible for AMSI bypass as shown in Figure 11.
Figure 11: AMSI bypass
agent3.ps1 (MD5: a3ee8655f45c72f5231ded7a4a1c7e43) contains the instructions to download Koi loader written in C++ as well as loading the shellcode in a separate thread along with the loader. The shellcode is responsible for allocating the memory for the loader and jumping to the loader’s entry point (Figure 12).
Figure 12: Shellcode that is responsible for accessing the loader at the entry point
Koi Loader
Anti-VM
The Koi Loader malware is written in C. The final loader payload is extracted and decrypted using XOR from the resource section, where the XOR key is also located.
We will proceed to the decrypted Koi payload. The loader begins by implementing the anti-CIS feature, which terminates the process if any of the languages listed in Figure 13 are detected.
Figure 13: Anti-CIS / language check
Additionally, the loader employs an anti-VM capability. It uses EnumDisplayDevicesW to enumerate display devices attached to the desktop, searching for device strings that match known virtual machine display adapters (Hyper-V, VMWare, Parallels, Red Hat QXL). It then checks for specific files related to VirtualBox (VBoxService.exe and VBoxTray.exe), indicating the system is running inside a VirtualBox VM.
The loader further inspects certain directories and files for evidence of a VM environment. This includes looking for specific files in the user's system and application data folders, which may indicate automated testing or sandboxing environments, such as Recently.docx, Opened.docx, These.docx, Resource.txt, OpenVPN.txt (Figure 14).
Figure 14: VirutalBox and file checks
Next, the loader retrieves the computer name and name of the currently logged-in user against WILLCARTER-PC, FORTI-PC, SFTOR-PC and Joe Cage, STRAZNJICA.GRUBUTT, Paul Jones, PJones, Harry Johnson, WDAGUtilityAccount, sal.rosenburg, and d5.vc/g accordingly. The computer name and username values can indicate automated analysis environments or generic usernames commonly used in virtual environments.
GlobalMemoryStatusEx is called to retrieve the system's memory status. It checks if the total physical is greater than or equal to 3050 MB. This check is performed to determine whether the system might be a VM or a typical end-user device, as analysis environments might allocate less memory to each VM instance.
Interestingly, the Koi Loader performs checks on files with extensions like doc, docx, xls, and xlsx. It verifies that these files are exactly 15 bytes in size and that their filenames contain 30 characters. Additionally, it assesses whether the total number of files matching these criteria is 20 or fewer, and if it does, it proceeds with another check for the presence of powershell.exe in the process's executable path.
If all these conditions are met, the loader interprets it as a sign that it might be running in a controlled or analysis environment (Figure 15).
Figure 15: File size and filename character check
The loader creates the mutex to avoid re-infection. The mutex creation algorithm is based on the calculations of the Volume Serial Number with other constants in the code. The reproduced algorithm is shown in Figure 16.
Additional Analysis
Figure 16: Mutex generation algorithm
Next, the loader proceeds with setting the file attributes of agent.js that was previously mentioned to hidden via SetFileAttributesW as well as creating the scheduled task named “Firefox Default Browser Agent 458046B0AF4A39CB” via ITaskScheduler interface that runs agent.js file via wscript.exe.
Command and Control
For the initial check-in, Koi Loader sends the following to the C2 as an example:
Where “VoYGkc5R” is the hardcoded marker followed by a randomly generated Base64-encoded string (Figure 17).
Figure 17: Initial check-in with C2
After the initial check-in, the infected machine sends another request containing the information gathered from the machine, including OSMajorVersion, OSMinorVersion, OSBuildNumber, Username, ComputerName, and the domain name if present. The collected information is then XOR'ed with a randomly generated 16-character value, which is subsequently processed via the modified MD5 algorithm and sent over to C2.
For the XOR key generation algorithm, the approach is to prepend a fixed byte sequence to the actual input data before hashing. This customizes the MD5 hashing process, making the output distinct from hashing the input alone with a standard MD5 algorithm. This customization affects how the data is processed and, consequently, the final hash.
The secondary POST request format:
111|{GUID}|{XOR’ed host information}
Figure 18: Secondary POST request with the host information
Next, the loader proceeds to check if NET Framework 2.0.50727 compiler exists on the infected host and if it exists, it downloads and executes “sd2.ps1” (MD5: 4f55be0b55ec67dfda42b88e9c743a2a) script from the server via PowerShell.
If the .NET 2.0 compiler does not exist, it then checks for the presence of .NET Framework 4.0.30319 compiler.
If this exists, the loader proceeds to download the "sd4.ps1" (MD5: 607b42bd61902ad5a5ea9f508e18a5a4) script instead (Figure 19).
Figure 19: Retrieving sd4.ps1 or sd2.ps1 scripts based on .NET Framework versions
We will analyze the "sd2.ps1" and "sd4.ps1" payloads later in this article. Now, let's return to the command-and-control part.
If the host receives the "INIT" response from the server, it resubmits the check-in to the server, as illustrated in Figure 17, appending the GUID value and a Base64-encoded string to the POST request. Otherwise, the host waits for additional tasks from the C2 server, with a one-minute sleep interval between each connection.
The list of commands/tasks is shown below:
Command
Description
0x67
Executes scripts/commands via Command Prompt
0x68
Executes scripts/commands via PowerShell
0x69
Enables system shutdown privilege for the running process and performs the shutdown
0x6A
Creates a scheduled task to run agent.js and removes agent.js if present on the host
0x6C
Establishes communication with a C2 server
0x6E
Performs process injection into either explorer.exe or certutil.exe based on the subsystem value (if the subsystem is Console User Interface, the payload is injected into certutil.exe, if it’s Graphical User Interface, the payload is injected into explorer.exe) or writes the payload to %TEMP% folder and directly executes it (the naming convention for the payload is generated with PRNG)
0x70
Dynamically loads and executes a function from a DLL, in our sample, the export function is “Release”
Koi Stealer
The retrieved scripts “sd2.ps1” and “sd4.ps1” include code for decrypting the final Koi Stealer binary using XOR, as well as for executing the binary with “config” parameters received from the C2 server.
The XOR key is obtained from the C2 server at the URL hxxp://91.202.233[.]209/index.php?id=$guid&subid=px8eIkut, where $guid represents the GUID of the infected machine (refer to Figure 20).
Figure 20: Snippet of “sd2.ps1” and “sd4.ps1” scripts
It's worth noting that the decrypted Koi Stealer payload exhibits similar anti-VM capabilities to those previously mentioned in the loader (see Figure 21).
Koi Stealer copies sensitive data, including cookies, history, and login information, to the %AppData% folder. For each copied file, it generates a unique GUID as a naming convention. The files are then immediately deleted after their contents have been fully processed (Figure 22).
Figure 22: Removing the copied files after processing
You can access the list of collected data for exfiltration on GitHub.
In the loader component, the program searches for the distinct identifier "LDR," retrieves commands from the C2 server, decodes them from Base64, and decrypts them using XOR with a shared secret as the key.
Subsequently, the secondary payload is downloaded from a URL provided by the C2 server and executed. The messages will be logged for successful or failed execution in the errors.txt file and sent over to C2 (Figure 23).
Figure 23: Logged messages
Koi Stealer collects the build ID of the payload, in our case it’s the second position of the previously mentioned “config”, which is “px8eIkut”, basic system information such as PC name, current username, GUID, GPU and CPU information, total visible RAM size, screen resolution, system configuration (system language, architecture, operating system), security software, installed applications and save them to a system.txt.
The infostealer generates a private-public key pair and a shared secret using the Curve25519 algorithm, then compresses the harvested data using GZip and encrypts it with XOR, employing the shared secret as the encryption key. Subsequently, it sends the data to the C2 server, with the POST request beginning with the public key, succeeded by a delimiter of 0x4b, and then the encrypted, compressed data (Figure 24).
Figure 24: Transmitted data
What can you learn from this TRU Positive?
Phishing emails remain a key vector for malware distribution, demonstrating the continuous threat of social engineering attacks and the need for ongoing vigilance.
The utilization of anti-VM capabilities by malware like Koi Loader and Koi Stealer highlights the attempts of modern threats to evade analysis and detection by analysts and researchers.
The case emphasizes the necessity of multi-layered security measures, including up-to-date antivirus or Endpoint Detection and Response (EDR) tools, to detect and block malicious activities.
Implementing Phishing and Security Awareness Training (PSAT) programs is crucial to educate employees about emerging threats and mitigate the risk of successful social engineering attacks.
The use of obfuscation and sophisticated delivery mechanisms by malware underscores the importance of implementing comprehensive detection strategies, including script logging and behavior-based detection mechanisms, to identify and mitigate threats.
What did we do?
Our 24/7 SOC Cyber Analysts investigated the suspicious activities, notified the customer, and isolated the affected device.
Recommendations from our Threat Response Unit (TRU) Team:
Ensure that all endpoints are protected with up-to-date antivirus software or Endpoint Detection and Response (EDR) tool capable of detecting and blocking malicious files.
We recommend modifying the default 'open-with' settings for script files, ensuring they open with a basic text editor like Notepad instead of executing.
Monitor unusual network traffic patterns, such as specific user-agent strings and data being sent used by malware to communicate with Command and Control (C2) servers, to identify potential compromises.
The eSentire Threat Response Unit (TRU) is an industry-leading threat research team committed to helping your organization become more resilient. TRU is an elite team of threat hunters and researchers that supports our 24/7 Security Operations Centers (SOCs), builds threat detection models across the eSentire XDR Cloud Platform, and works as an extension of your security team to continuously improve our Managed Detection and Response service. By providing complete visibility across your attack surface and performing global threat sweeps and proactive hypothesis-driven threat hunts augmented by original threat research, we are laser-focused on defending your organization against known and unknown threats.
Cookies allow us to deliver the best possible experience for you on our website - by continuing to use our website or by closing this box, you are consenting to our use of cookies. Visit our Privacy Policy to learn more.
