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:
Pip install command
File name
First upload date
Author / Email
pip install uuid32-utils
uuid32_utils-1.x.x-py3-none-[OS platform].whl
2025-07-16
laz**** / laz****@tutamail.com
pip install colorinal
colorinal-0.1.7-py3-none-[OS platform].whl
2025-07-22
sym**** / sym****@proton.me
pip install termncolor
termncolor-3.1.0-py3-none-any.whl
2025-07-22
sym**** / sym****@proton.me
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:
Deploy ZiChatBot.
Establish an auto-run mechanism.
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:
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.
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.
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.
A major software supply chain attack has compromised the popular Python package elementary-data, exposing thousands of developers to massive credential theft.
Threat actors successfully pushed a malicious version, 0.23.3, to the Python Package Index (PyPI) and poisoned the matching Docker images on the GitHub Container Registry (GHCR).
With over one million monthly downloads, this widely used dbt data observability tool represents a highly lucrative target for cybercriminals.
As detailed by StepSecurity researchers, the attack did not rely on stolen developer passwords.
the original community report (source : stepsecurity )
A newly created GitHub account posted a malicious script in an open pull request comment.
Because the automated workflow failed to process this comment safely, the system executed the code.
Using the workflow’s built-in access token, the attacker forged a verified release commit and triggered the official publishing process without ever touching the main codebase.
The malicious elementary-data 0.23.3 release was listed as the latest on PyPI (Source: stepsecurity)
Once installed, the compromised package drops a single malicious file named elementary.pth into the environment.
Since Python automatically runs .pth files whenever the interpreter starts, the malware activates immediately on any machine where the package is installed.
According to threat intelligence reports, the payload is a sophisticated, three-stage information stealer that actively hunts for critical developer secrets and credentials.
It systematically targets and steals:
Cloud access tokens for AWS, Google Cloud, and Azure.
Multiple cryptocurrency wallets, including Bitcoin and Ethereum.
All stolen data is compressed into an archive and silently sent to a remote, attacker-controlled command-and-control server.
The malicious elementary.pth file shipped inside the wheel(source : stepsecurity)
Affected Versions
To check if you are impacted, StepSecurity advises reviewing your installed builds.
The compromised version of the elementary-data PyPI package is 0.23.3. However, users are safe if they use version 0.23.4 or the earlier 0.23.2.
Similarly, the affected Docker image is ghcr.io/elementary-data/elementary:0.23.3, while version 0.23.4 (or 0.23.2) is clean.
Furthermore, if you are using the latest Docker image tag with a digest ending in 634255, your environment is compromised.
The injected payload running inside the workflow (source: stepsecurity)
StepSecurity warns that you must ensure your latest tag is updated to the newly provided clean build.
Thanks to the quick action of community members Crisperik and H-Max, who spotted the malicious code, the maintainers were alerted within hours.
The Elementary team immediately removed the dangerous 0.23.3 version from PyPI and GHCR, releasing a clean 0.23.4 replacement the same day.
Developers who were exposed to the malicious update must fully rotate all credentials, API keys, and database passwords on the affected machines.
Enable two-factor authentication on all vital infrastructure and pin future package dependencies to specific, verified versions to stop automatic malicious updates.
A security vulnerability has been discovered in Python’s Windows asyncio implementation, allowing attackers to trigger out-of-bounds memory writes through a missing boundary check in network socket operations.
The vulnerability, tracked as CVE-2026-3298, carries a high severity rating. It exclusively affects Windows platforms and was publicly disclosed on April 21, 2026.
The flaw exists in the sock_recvfrom_into() method of Python’s asyncio.proactorEventLoop class, which is Windows’ native event loop implementation.
When the optional nbytes parameter is used, the method fails to validate whether the incoming network data exceeds the destination buffer size.
As a result, data larger than the allocated buffer could be written beyond its intended memory boundary, creating a classic out-of-bounds write condition.
Out-of-bounds write vulnerabilities are particularly dangerous because they can corrupt adjacent memory regions.
Depending on the runtime environment and how memory is managed, this can potentially lead to application crashes, arbitrary code execution, or privilege escalation.
Windows Python Vulnerability
Only Windows users running Python with asyncio-based network applications are at risk. Specifically, applications that use ProactorEventLoop Python’s default event loop on Windows and invoke sock_recvfrom_into() with the nbytes parameter are vulnerable.
Linux and macOS platforms are not affected, as they rely on a different event loop implementation (SelectorEventLoop) that does not contain this flaw.
The root cause is a missing boundary check introduced in the ProactorEventLoop's socket receive logic.
When a caller specifies nbytes to limit the amount of data read into a buffer, the function does not verify that the actual data received fits within that limit.
This allowed network-supplied data to overflow the buffer during an async receive operation. Seth Larson reported the vulnerability and officially disclosed it through the Python Security Announce mailing list.
Mitigations
The Python development team has issued a fix via a pull request to the CPython repository on GitHub (PR #148809). Users are strongly advised to:
Update Python to the latest patched version immediately.
Review asyncio-based Windows applications using sock_recvfrom_into() with the nbytes parameter.
Monitor the official CVE record for details on the affected version and further updates.
This vulnerability highlights the ongoing risk of missing input validation in low-level async I/O operations.
Windows-based Python deployments running networked asyncio applications should treat this as a high-priority patch given its high severity and potential for memory corruption.
A high-severity security vulnerability has been discovered in Python’s asyncio module on Windows, potentially allowing attackers to write data beyond the boundaries of an allocated memory buffer. The flaw, tracked as CVE-2026-3298, was publicly disclosed on April 21, 2026, by Python security developer Seth Larson via the official Python security announcement mailing list. The vulnerability exists in the sock_recvfrom_into() method […]
Overview ahnLab monitored APT attacks against domestic targets during the month of March 2026. most of the attacks were launched through Spear Phishing emails sent after reconnaissance of specific targets. APT Attack Trends in Korea the majority of distribution vectors were shortcut (.lnk) files, with LNK-based attacks dominating. Type A is to run PowerShell with […]
Hackers are abusing a stealthy Python backdoor called VIPERTUNNEL, hiding it behind a fake DLL file and a multi‑stage obfuscated loader to quietly tunnel traffic out of victim networks. A review of persistence mechanisms revealed a sitecustomize.py file in C:\ProgramData\cp49s\Lib\. This special Python module auto‑loads at interpreter startup and can silently run code without command‑line input. This script used ctypes to […]
Kimsuky is using multi-stage malicious LNK files to deploy a Python-based backdoor, adding new intermediate scripts while keeping the final payload logic largely unchanged. The campaign abuses Windows Task Scheduler, Dropbox, and bundled Python runtimes to evade detection and maintain persistence on infected systems. The ZIP contained a Python script (can.py), a standalone Python interpreter, […]
The popular Telnyx Python SDK on PyPI to deploy a multi‑stage credential‑stealing operation that targets cloud infrastructure, Kubernetes clusters, and developer environments at scale. On March 27, 2026, TeamPCP uploaded two malicious Telnyx SDK releases, versions 4.87.1 and 4.87.2, directly to PyPI at around 03:51 UTC, bypassing the normal GitHub‑backed release flow used by the […]
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).
A widely used open-source Python library was compromised on the Python Package Index (PyPI). Versions 1.82.7 and 1.82.8 of the package, which route requests across various LLM providers and have over 95 million monthly downloads, were found to contain a sophisticated backdoor by security vendors Endor Labs and JFrog.
The malicious code was injected directly into the PyPI distribution, bypassing the clean upstream GitHub repository. This supply chain attack is attributed to TeamPCP, a threat actor known for targeting highly privileged developer and security tools.
The infection chain relies on malicious code execution disguised within legitimate library functions. In version 1.82.7, attackers injected a 12-line base64-encoded payload into the litellm/proxy/proxy_server.py file. This code triggers silently upon module import.
Version 1.82.8 escalates the threat by introducing a litellm_init.pth file into the root of the wheel. Because Python automatically processes .pth files placed in site-packages at startup, this secondary vector ensures the payload executes as a background process during any Python invocation in the compromised environment. This means the payload triggers even if litellm is never explicitly imported by the developer’s code.
Note: The last known-clean version is litellm 1.82.6.
Upon execution, the payload initiates an aggressive three-stage attack sequence. The initial orchestrator script unpacks a comprehensive credential harvester designed to systematically sweep the host system.
It targets SSH keys, cloud provider tokens for AWS, GCP, and Azure, database credentials, and cryptocurrency wallets. Extracted secrets are encrypted using a hybrid AES-256-CBC and RSA-4096 scheme and bundled into an archive named tpcp.tar.gz before being exfiltrated to an attacker-controlled domain masquerading as a legitimate project resource.
Beyond credential theft, the malware attempts lateral movement within Kubernetes environments. If the harvester detects a Kubernetes service account token, it rapidly enumerates all cluster nodes and deploys privileged alpine containers to each node using host-level access.
Finally, the malware establishes persistent access by dropping a systemd user service disguised as a system telemetry process. This backdoor continuously polls a secondary command-and-control server to fetch and execute additional binaries.
This breach represents the latest escalation in a sprawling supply chain campaign orchestrated by TeamPCP. Over the past month, the group has successfully compromised five separate ecosystems, including GitHub Actions, Docker Hub, npm, and OpenVSX.
By deliberately targeting infrastructure and security-focused tools such as Aqua Security’s Trivy and Checkmarx’s KICS, the attackers ensure their payloads execute in highly privileged environments rich with production secrets.
Key Indicators of Compromise (IoCs)
Indicator
Type
Description
models.litellm.cloud
C2 Domain
Exfiltration endpoint for encrypted credential archives
checkmarx.zone/raw
C2 Endpoint
Payload delivery domain for the persistent backdoor
~/.config/systemd/user/sysmon.service
Filesystem
Persistent systemd unit hiding the backdoor
tpcp.tar.gz
Archive
Named archive containing exfiltrated host data
node-setup-*
Kubernetes
Privileged attacker pods deployed in the kube-system namespace
Organizations utilizing litellm should immediately audit their environments. If the compromised versions are detected, security teams must treat the environment as fully breached and initiate a comprehensive credential rotation protocol.
In October 2025, we discovered a series of forum posts advertising a previously unknown stealer, dubbed “Arkanix Stealer” by its authors. It operated under a MaaS (malware-as-a-service) model, providing users not only with the implant but also with access to a control panel featuring configurable payloads and statistics. The set of implants included a publicly available browser post-exploitation tool known as ChromElevator, which was delivered by a native C++ version of the stealer. This version featured a wide range of capabilities, from collecting system information to stealing cryptocurrency wallet data. Alongside that, we have also discovered Python implementation of the stealer capable of dynamically modifying its configuration. The Python version was often packed, thus giving the adversary multiple methods for distributing their malware. It is also worth noting that Arkanix was rather a one-shot malicious campaign: at the time of writing this article, the affiliate program appears to be already taken down.
Kaspersky products detect this threat as Trojan-PSW.Win64.Coins.*, HEUR:Trojan-PSW.Multi.Disco.gen, Trojan.Python.Agent.*.
Technical details
Background
In October 2025, a series of posts was discovered on various dark web forums, advertising a stealer referred to by its author as “Arkanix Stealer”. These posts detail the features of the stealer and include a link to a Discord server, which serves as the primary communication channel between the author and the users of the stealer.
Example of an Arkanix Stealer advertisement
Upon further research utilizing public resources, we identified a set of implants associated with this stealer.
Initial infection or spreading
The initial infection vector remains unknown. However, based on some of the file names (such as steam_account_checker_pro_v1.py, discord_nitro_checker.py, and TikTokAccountBotter.exe) of the loader scripts we obtained, it can be concluded with high confidence that the initial infection vector involved phishing.
Python loader
MD5
208fa7e01f72a50334f3d7607f6b82bf
File name
discord_nitro_code_validator_right_aligned.py
The Python loader is the script responsible for downloading and executing the Python-based version of the Arkanix infostealer. We have observed both plaintext Python scripts and those bundled using PyInstaller or Nuitka, all of which share a common execution vector and are slightly obfuscated. These scripts often serve as decoys, initially appearing to contain legitimate code. Some of them do have useful functionality, and others do nothing apart from loading the stealer. Additionally, we have encountered samples that employ no obfuscation at all, in which the infostealer is launched in a separate thread via Python’s built-in threading module.
Variants of Python loaders executing the next stage
Upon execution, the loader first installs the required packages — namely, requests, pycryptodome, and psutil — via the pip package manager, utilizing the subprocess module. On Microsoft Windows systems, the loader also installs pywin32. In some of the analyzed samples, this process is carried out twice. Since the loader does not perform any output validation of the module installation command, it proceeds to make a POST request to hxxps://arkanix[.]pw/api/session/create to register the current compromised machine on the panel with a predefined set of parameters even if the installation failed. After that, the stealer makes a GET request to hxxps://arkanix[.]pw/stealer.py and executes the downloaded payload.
Python stealer version
MD5
af8fd03c1ec81811acf16d4182f3b5e1
File name
–
During our research, we obtained a sample of the Python implementation of the Arkanix stealer, which was downloaded from the endpoint hxxps://arkanix[.]pw/stealer.py by the previous stage.
The stealer’s capabilities — or features, as referred to by the author — in this version are configurable, with the default configuration predefined within the script file. To dynamically update the feature list, the stealer makes a GET request to hxxps://arkanix[.]pw/api/features/{payload_id}, indicating that these capabilities can be modified on the panel side. The feature list is identical to the one that was described in the GDATA report.
Configurable options
Prior to executing the information retrieval-related functions, the stealer makes a request to hxxps://arkanix[.]pw/upload_dropper.py, saves the response to %TEMP%\upd_{random 8-byte name}.py, and executes it. We do not have access to the contents of this script, which is referred to as the “dropper” by the attackers.
During its main information retrieval routine, at the end of each processing stage, the collected information is serialized into JSON format and saved to a predefined path, such as %LOCALAPPDATA\Arkanix_lol\%info_class%.json.
In the following, we will provide a more detailed description of the Python version’s data collection features.
System info collection
Arkanix Stealer is capable of collecting a set of info about the compromised system. This info includes:
OS version
CPU and GPU info
RAM size
Screen resolution
Keyboard layout
Time zone
Installed software
Antivirus software
VPN
Information collection is performed using standard shell commands with the exception of the VPN check. The latter is implemented by querying the endpoint hxxps://ipapi[.]co/json/ and verifying whether the associated IP address belongs to a known set of VPNs, proxies, or Tor exit nodes.
Browser features
This stealer is capable of extracting various types of data from supported browsers (22 in total, ranging from the widely popular Google Chrome to the Tor Browser). The list of supported browsers is hardcoded, and unlike other parameters, it cannot be modified during execution. In addition to a separate Chrome grabber module (which we’ll discuss later), the stealer itself supports the extraction of diverse information, such as:
Browser history (URLs, visit count and last visit)
Autofill information (email, phone, addresses and payment cards details)
Saved passwords
Cookies
In case of Chromium-based browsers, 0Auth2 data is also extracted
All information is decrypted using either the Windows DPAPI or AES, where applicable, and searched for relevant keywords. In the case of browser information collection, the stealer searches exclusively for keywords related to banking (e.g., “revolut”, “stripe”, “bank”) and cryptocurrencies (e.g., “binance”, “metamask”, “wallet”). In addition to this, the stealer is capable of extracting extension data from a hardcoded list of extensions associated with cryptocurrencies.
Part of the extension list which the stealer utilizes to extract data from
Telegram info collection
Telegram data collection begins with terminating the Telegram.exe process using the taskkill command. Subsequently, if the telegram_optimized feature is set to False, the malware zips the entire tdata directory (typically located at %APPDATA%\Roaming\Telegram Desktop\tdata) and transmits it to the attacker. Otherwise, it selectively copies and zips only the subdirectories containing valuable info, such as message log. The generated archive is sent to the endpoint /delivery with the filename tdata_session.zip.
Discord capabilities
The stealer includes two features connected with Discord: credentials stealing and self-spreading. The first one can be utilized to acquire credentials both from the standard client and custom clients. If the client is Chromium-based, the stealer employs the same data exfiltration mechanism as during browser credentials stealing.
The self-spreading feature is configurable (meaning it can be disabled in the config). The stealer acquires the list of user’s friends and channels via the Discord API and sends a message provided by the attacker. This stealer does not support attaching files to such messages.
VPN data collection
The VPN collector is searching for a set of known VPN software to extract account credentials from the credentials file with a known path that gets parsed with a regular expression. The extraction occurs from the following set of applications:
Mullvad VPN
NordVPN
ExpressVPN
ProtonVPN
File retrieval
File retrieval is performed regardless of the configuration. The script relies on a predefined set of paths associated with the current user (such as Desktop, Download, etc.) and file extensions mainly connected with documents and media. The script also has a predefined list of filenames to exfiltrate. The extracted files are packed into a ZIP archive which is later sent to the C2 asynchronously. An interesting aspect is that the filename list includes several French words, such as “motdepasse” (French for “password”), “banque” (French for “bank”), “secret” (French for “secret”), and “compte” (French for “account”).
Other payloads
We were able to identify additional modules that are downloaded from the C2 rather than embedded into the stealer script; however, we weren’t able to obtain them. These modules can be described by the following table, with the “Details” column referring to the information that could be extracted from the main stealer code.
Module name
Endpoint to download
Details
Chrome grabber
/api/chrome-grabber-template/{payload_id}
–
Wallet patcher
/api/wallet-patcher/{payload_id}
Checks whether “Exodus” and “Atomic” cryptocurrency wallets are installed
Extra collector
/api/extra-collector/{payload_id}
Uses a set of options from the config, such as collect_filezilla, collect_vpn_data, collect_steam, and collect_screenshots
HVNC
/hvnc
Is saved to the Startup directory (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\hvnc.py) to execute upon system boot
The Wallet patcher and Extra collector scripts are received in an encrypted form from the C2 server. To decrypt them, the attackers utilize the AES-GCM algorithm in conjunction with PBKDF2 (HMAC and SHA256). After decryption, the additional payload has its template placeholders replaced and is stored under a partially randomized name within a temporary folder.
Decryption routine and template substitution
Once all operations are completed, the stealer removes itself from the drive, along with the artifacts folder (Arkanix_lol in this case).
Native version of stealer
MD5
a3fc46332dcd0a95e336f6927bae8bb7
File name
ArkanixStealer.exe
During our analysis, we were able to obtain both the release and debug versions of the native implementation, as both were uploaded to publicly available resources. The following are the key differences between the two:
The release version employs VMProtect, but does not utilize code virtualization.
The debug version communicates with a Discord bot for command and control (C2), whereas the release version uses the previously mentioned C2 domain arkanix[.]pw.
The debug version includes extensive logging, presumably for the authors’ debugging purposes.
Notably, the native implementation explicitly references the name of the stealer in the VersionInfo resources. This naming convention is consistent across both the debug version and certain samples containing the release version of the implant.
Version info
After launching, the stealer implements a series of analysis countermeasures to verify that the application is not being executed within a sandboxed environment or run under a debugger. Following these checks, the sample patches AmsiScanBuffer and EtwEventWrite to prevent the triggering of any unwanted events by the system.
Once the preliminary checks are completed, the sample proceeds to gather information about the system. The list of capabilities is hardcoded and cannot be modified from the server side, in contrast to the Python version. What is more, the feature list is quite similar to the Python version except a few ones.
RDP connections
The stealer is capable of collecting information about known RDP connections that the compromised user has. To achieve this, it searches for .rdp files in %USERPROFILE%\Documents and extracts the full server address, password, username and server port.
Gaming files
The stealer also targets gamers and is capable to steal credentials from the popular gaming platform clients, including:
Steam
Epic Games Launcher
net
Riot
Origin
Unreal Engine
Ubisoft Connect
GOG
Screenshots
The native version, unlike its Python counterpart, is capable of capturing screenshots for each monitor via capCreateCaptureWindowA WinAPI.
In conclusion, this sample communicates with the C2 server through the same endpoints as the Python version. However, in this instance, all data is encrypted using the same AES-GCM + PBKDF2 (HMAC and SHA256) scheme as partially employed in the Python variant. In some observed samples, the key used was arkanix_secret_key_v20_2024. Alongside that, the C++ sample explicitly sets the User-Agent to ArkanixStealer/1.0.
Post-exploitation browser data extractor
MD5
3283f8c54a3ddf0bc0d4111cc1f950c0
File name
–
This is an implant embedded within the resources of the C++ implementation. The author incorporated it into the resource section without applying any obfuscation or encryption. Subsequently, the stealer extracts the payload to a temporary folder with a randomly generated name composed of hexadecimal digits (0-9 and A-F) and executes it using the CreateProcess WinAPI. The payload itself is the unaltered publicly available project known as “ChromElevator”. To summarize, this tool consists of two components: an injector and the main payload. The injector initializes a direct syscall engine, spawns a suspended target browser process, and injects the decrypted code into it via Nt syscalls. The injected payload then decrypts the browser master key and exfiltrates data such as cookies, login information, web data, and so on.
Infrastructure
During the Arkanix campaign, two domains used in the attacks were identified. Although these domains were routed through Cloudflare, a real IP address was successfully discovered for one of them, namely, arkanix[.]pw. For the second one we only obtained a Cloudflare IP address.
Domain
IP
First seen
ASN
arkanix[.]pw
195.246.231[.]60
Oct 09, 2025
–
arkanix[.]ru
172.67.186[.]193
Oct 19, 2025
–
Both servers were also utilized to host the stealer panel, which allows attackers to monitor their victims. The contents of the panel are secured behind a sign-in page. Closer to the end of our research, the panel was seemingly taken down with no message or notice.
Stealer panel sign-in page
Stealer promotion
During the research of this campaign, we noticed that the forum posts advertising the stealer contained a link leading to a Discord server dubbed “Arkanix” by the authors. The server posed as a forum where authors posted various content and clients could ask various questions regarding this malicious software. While users mainly thank and ask about when the feature promised by the authors will be released and added into the stealer, the content made by the authors is broader. The adversary builds up the communication with potential buyers using the same marketing and communication methods real companies employ. To begin with, they warm up the audience by posting surveys about whether they should implement specific features, such as Discord injection and binding with a legitimate application (sic!).
Feature votes
Additionally, the author promised to release a crypter as a side project in four to six weeks, at the end of October. As of now, the stealer seems to have been taken down without any notice while the crypter was never released.
Arkanix Crypter
Furthermore, the Arkanix Stealer authors decided to implement a referral program to attract new customers. Referrers were promised an additional free hour to their premium license, while invited customers received seven days of free “premium” trial use. As stated in forum posts, the premium plan included the following features:
C++ native stealer
Exodus and Atomic cryptocurrency wallets injection
Increased payload generation, up to 10 payloads
Priority support
Referral program ad and corresponding panel interface
Speaking of technical details, based on the screenshot of the Visual Studio stealer project that was sent to the Discord server, we can conclude that the author is German-speaking.
This same screenshot also serves as a probable indicator of AI-assisted development as it shares the common patterns of such assistants, e.g. the presence of the utils.cpp file. What provides even more confidence is the overall code structure, the presence of comments and extensive debugging log output.
Example of LLM-specific patterns
Conclusions
Information stealers have always posed as a serious threat to users’ data. Arkanix is no exception as it targets a wide range of users, from those interested in cryptocurrencies and gaming to those using online banking. It collects a vast amount of information including highly sensitive personal data. While being quite functional, it contains probable traces of LLM-assisted development which suggests that such assistance might have drastically reduced development time and costs. Hence it follows that this campaign tends to be more of a one-shot campaign for quick financial gains rather than a long-running infection. The panel and the Discord chat were taken down around December 2025, leaving no message or traces of further development or a resurgence.
In addition, the developers behind the Arkanix Stealer decided to address the public, implementing a forum where they posted development insights, conducted surveys and even ran a referral program where you could get bonuses for “bringing a friend”. This behavior makes Arkanix more of a public software product than a shady stealer.
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.
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.
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:
Screenshot of renamed Word 2013 executable to lure the user
The other files extracted from the archive are hidden from the user in Windows Explorer but shown below:
Extracted contents of the archive, including hidden files
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.
Screenshot of the non-malicious decoy document
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.
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.
Browsers targeted by the injected DLL from the July campaign
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:
360Browser
Chromium
Opera Crypto
360 Extreme Browser
CocCoc
Opera GX
Aloha
CryptoTab
QQBrowser
Amigo
Dragon
Sidekick
Arc
Edge
Slimjet
Avast
Epic
Sogou
AVG
Ghost
Speed360
Brave
Iridium
SRWare
Brave Nightly
Liebao
Thorium
CCleaner
Liebao AI
UR Browser
Cent
Maxthon
Vivaldi
Chedot
Naver
Wavebox
Chrome
Opera
Yandex
The malware targets the following list of cryptocurrency wallet related browser extensions:
Ambire
ExodusWeb3
SafePal Wallet
Aptos Wallet
Frame
Station Wallet
Argent X
Keystone Wallet
Sui Wallet
Atomic Wallet
Leather Bitcoin Wallet
Talisman Wallet
Backpack Wallet
Ledger Live
Tonkeeper Wallet
Bitapp
Leo Wallet
TON Wallet
Bitget Wallet
Magic Eden Wallet
Uniswap Wallet
Bitski Wallet
MathWallet
Wallet Guard
Cosmostation Wallet
MyTonWallet
Zeal
Crocobit
OpenMask Wallet
Zeeve Wallet
Crypto.com
Portal DEX Wallet
Zerion
Edge Wallet
Pulse Wallet Chromium
Equal
Quai Wallet
User databases and configuration files for the following applications are targeted, many of which house sensitive data or cryptocurrency assets:
Armory
Dogecoin
Ledger Live
Atomic
Electron Cash
Litecoinwallets
Azure
Electrum
Monero
Binance
ElectrumLTC
Multidoge
Bitcoin Core
Ethereum
MyMonero
Blockstream Green
Exodus
OpenVPN
bytecoin
FileZilla
ProtonVPN
Chia Wallet
Guarda Desktop
Raven Core
Coinomi
Jaxx Desktop
Telegram
Daedalus Mainnet
KeePass
Wasabi Wallet
DashCorewallets
Komodo Wallet
Zcash
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:
ads.google.com
coinomi.co.nl
korbit.co.kr
adsmanager.facebook.com
coinone.co.kr
kraken.com
binance.com
coinplug.ng
kucoin.com
bingx.com
crypto.com
lbank.com
bitfinex.com
electrum.org
mexc.com
bitget.com
exodus.com
nami.exchange
bitgo.com
gate.com
okx.com
bitmart.com
gemini.com
paypal.com
bitunix.com
gopax.co.kr
probit.com
business.facebook.com
htx.com
upbit.com
bybit.com
huobi.com
whitebit.com
coinbase.com
hyperliquid.xyz
xt.com
The specific Telegram Bot Token, and associated Chat ID, identified in the samples from July are:
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)
Exfiltrated Victim Data from MRB_NEW_VER_BOT via PXA Stealer
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:
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:
Bio and Info fields from Telegram profiles masquerading as bots
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.
Obfuscated Python code hosted on Paste[.]rsOnce downloaded, the obfuscated Python code is decoded and executed, delivering the Infostealer component of the attack.
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.
Lone None Telegram ChatIDReference to LoneNone TG channel in decoded (July) infostealer
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:
Probiv[.]gg contains a redirect to the Sherlock Telegram Bot Service, which provides a search interface for data culled from infostealers.
Telegram redirect on probiv[.]ggThe redirect leads to the Telegram landing page for SherLock1u_BOT, a provider of stolen data, and the automated services to search for specific data types or sets.
SherLock1u_BOT
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.
South Korea victim data uploaded to Telegram via PXA Stealer
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.
Adonis (ADN_2_NEW_BOT) victim records
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:
Republic of Korea (KR)
United States (US)
Netherlands (NL)
Hungary (HU)
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.
Entrar
