Written by: Jordan Jones
Introduction
Google Threat Intelligence Group (GTIG) has conducted an in-depth analysis of a .NET backdoor, tracked as STOCKSTAY, that has been continually developed and deployed by the Russia-linked threat actor Turla (aka SUMMIT, Secret Blizzard, VENOMOUS BEAR, UAC-0194) since at least December 2022. Turla has deployed STOCKSTAY against government and military organizations in Ukraine, as well as entities with an interest in Italian foreign policy. Used for ongoing cyber espionage, this backdoor shares significant code and functional overlaps with KAZUAR, a successful toolkit previously attributed to Turla. The group has a long history of targeting a wide range of industries, with a particular focus on western Ministries of Foreign Affairs, and defense organizations within the context of heightened political tensions.
Turla, and specifically their longstanding Snake implant, has been publicly attributed by the United States Cybersecurity and Infrastructure Security Agency (CISA) to Center 16 of Russia’s Federal Security Service (FSB). Turla is one of the oldest known cyber espionage groups with suspected activity dating back to at least 2004. The actor remains active and continues to evolve its delivery methods, as demonstrated by its deployment of specialized scripts to intercept secure communications from Signal Messenger users, its hijacking of legacy criminal botnets to target Ukrainian organizations, and its recent campaigns targeting military defense sectors using the highly sophisticated KAZUAR toolkit. As part of our continued tracking of this group, this blog post provides an overview of our STOCKSTAY analysis, includes a timeline of key developmental and operational observations, and examines its similarities to KAZUAR to contextualize this new capability within Turla’s ever-growing arsenal.
STOCKSTAY Overview
STOCKSTAY is a multi-component backdoor written in .NET, using the Windows Forms framework, which communicates with its command and control (C2) via a secure WebSocket connection, utilizing the open-source websocket-sharp library. STOCKSTAY consists of several distinct components that communicate with one another via an inter-process communication (IPC) channel, based on the exchange of WM_COPYDATA messages.
STOCKSTAY was originally designed to masquerade as a stock market data viewing tool, incorporating this disguise in both its file naming scheme and its storage of implant configuration, control messages, and response data. While initial versions of the malware observed by GTIG retained the internal aspects of this disguise, in 2025 we identified variants of STOCKSTAY masquerading as other benign applications, such as PDF viewers and calculator utilities.
Figure 1: Overview of STOCKSTAY malware architecture
STOCKSTAY.STOCKBROKER
STOCKSTAY.STOCKBROKER is a proxy-aware tunneler which provides network communication capabilities to the wider STOCKSTAY ecosystem. STOCKSTAY.STOCKBROKER, internally referred to as "net", can be instructed to establish a secure WebSocket connection to a specified remote server, after which it acts as a relay between the server and the STOCKSTAY.STOCKMARKET orchestrator. As a result, all C2 communication between STOCKSTAY and the configured C2 server are handled by STOCKSTAY.STOCKBROKER, isolating the malware’s network communications from other malicious host-based activity on the infected machine.
STOCKSTAY.STOCKMARKET
STOCKSTAY.STOCKMARKET, internally referred to as “cor”, is the orchestrator of the STOCKSTAY ecosystem, and enables the implant’s configurability. The malware’s configuration is loaded from an encrypted on-disk configuration file which specifies several options regarding the malware’s execution, including the details of the remote WebSocket server required by STOCKSTAY.STOCKBROKER. The configuration file attempts to disguise itself as a legitimate file by including various legitimate URLs associated with cryptocurrency markets, as well as falsified descriptions of each configuration field (Figure 2). Encrypted configuration data is embedded within the decoy fields, which is decrypted by STOCKSTAY.STOCKMARKET.
{ "Name": "StockMarket", "Description": "An application for getting information about current events on trading platforms. To set the time for updating information, enter a value in minutes in the `Interval` field. In the future, support for themes will be added. The `SystemConfiguration` field stores the system settings of the application. In the `services` field, fill in the list of addresses of services that provide the `WebSocket protocol`.", "Theme": "Dark", "SystemConfiguration": [ "1D.AA.79.9F.45.AA.04.B3..68.0A.5D.A3.E6.A3.82.FA", "6F.41.4D.6D.C3.20.E5.32..00.B8.26.DF.E1.13.0A.21", "4.4.3.12" ], "Interval": 10, "Services": [ "wss://ws-api.binance.com:443/ws-api/v3", "wss://ws-feed.exchange.coinbase.com", "wss://ws-feed-public.sandbox.exchange.coinbase.com", "wss://stream.bybit.com/v5/public/spot", "wss://stream.bybit.com/v5/public/linear" ], "Version": "2022-12-21" }Figure 2: Encrypted STOCKSTAY configuration file format, falsely describing itself as an application for trading information
{ "internal_id": "", "internal_key": "", "interval_engine": "600000", "level_info": "0", "time_scale": "1", "span_min": "9", "span_max": "18", "rate": "2700", "rate_control": "false", "service": "", "days_not_work": "Saturday;Sunday;", "system_properties": "eyJzeXN0ZW1fZGF0YV9zaXplIjoiNDAwMDAwIn0=" }Figure 3: Decrypted STOCKSTAY configuration file format (extracted from SystemConfiguration field)
STOCKSTAY.STOCKMARKET communicates with STOCKSTAY.STOCKBROKER in order to provide details of the WebSocket server, and to subsequently send and receive messages via the established WebSocket connection, usually containing the results of executed commands. STOCKSTAY.STOCKMARKET also communicates with the STOCKSTAY.STOCKTRADER component in order to issue commands to be executed on the infected host.
On first execution, STOCKSTAY.STOCKMARKET generates a unique 4096-bit RSA key pair, to be used throughout the implant’s lifecycle to encrypt outbound data prior to being sent via WebSocket. The implant’s public key is sent to the server in the malware’s first request, to enable the server to decrypt task responses. STOCKSTAY.STOCKMARKET also generates a unique infection identifier to be used by the C2 server to determine the intended receiver of tasking. STOCKSTAY’s configuration file specifies an “internal_id” field, which GTIG assesses represents an identifier for the server-side component of the malware ecosystem. We assess that this identifier is used by the malware’s operators to retrieve responses from interim C2 servers which may be used by multiple operators. To date, GTIG has observed only a single unique value for this identifier and is unable to determine whether multiple operators are leveraging STOCKSTAY at this time due to insufficient telemetry.
STOCKSTAY.STOCKTRADER
STOCKSTAY.STOCKTRADER, internally referred to as “sys”, is the backdoor component of the STOCKSTAY ecosystem, and supports a range of registry, file, and command execution operations on the infected host, as detailed in Table 1.
| Task Command Name | Description |
|---|---|
|
| Delete the specified files. Requires a semi-colon-separated list of file paths, each of which will be deleted. Confirmation of each deleted file, or deletion failure, is returned to the C2. |
|
| Generate a listing of the specified directories. Requires a semi-colon-separated list of directory paths, each of which will be enumerated with the paths of all contained files and subdirectories being returned to the C2. Optionally performs recursive directory listing. |
|
| Retrieve one or more specified files. Allows for collection of files with specific extensions. Requires a semi-colon-separated list of file or directory paths, and a list of target file extensions. If a file path is included in the list, this file will be returned. If instead a directory path is included in the list, the malware will perform an optionally recursive search of the directory to identify any files matching the target file extensions. All files matching either the specified file paths, or the target file extensions, will be added to an in-memory ZIP archive and subsequently base64-encoded for transmission to the C2. |
|
| Perform a screen-capture of the victim’s screen. The resultant image is base64-encoded for transmission to the C2. |
|
| Create one or more directories. Requires a semi-colon-separated list of directory paths, each of which will be created. Confirmation of each created directory, or any resultant error, is returned to the C2. |
|
| Process multiple tasks at once. Requires a semi-colon-separated list of tasks, each of which must be a serialized JSON object containing an individual task. Each task is submitted to the malware’s command-manager in-turn, with all command output being discarded; no data is returned to the C2 when processing multiple tasks at once. |
|
| Upload a file to the device. Requires a base64-encoded string representation of the file content to be written to the specified filepath. The required file write operation is performed in “Append” mode. Confirmation of file upload, or details of any relevant error, is returned to the C2. |
|
| Delete a registry value. Requires a registry key and corresponding value name to delete. |
|
| Read a registry value. Requires a registry key and corresponding value name to read. |
|
| Set a registry value. Requires a registry key and corresponding value name, as well as the value and data type used to populate the registry value. |
|
| Delete the specified directories. Requires a semi-colon-separated list of directory paths, each of which will be deleted. Confirmation of each deleted directory, or deletion failure, is returned to the C2. |
|
| Execute a new process. Requires a path to the file to execute and its corresponding arguments. A default timeout of 60 seconds is hard-coded into the malware, however this can be overridden by the task configuration. All subprocesses are created windowless with redirected stdout. |
|
| Conduct a system survey to gather key information about the infected host. Operating system information is collected via the Windows Management Instrumentation (WMI) ManagementObjectSearcher, specifically the following fields:
With respect to hardware, WMI is queried for the following:
The malware also captures a list of the names of running processes. |
|
| Extract the specified ZIP file to its current directory. |
Table 1: Backdoor commands supported by STOCKSTAY.STOCKTRADER
Related Downloaders and Installers
STOCKSTAY.MARKETMAKER
STOCKSTAY.MARKETMAKER is a proxy-aware downloader written in .NET using the Windows Forms framework that downloads and extracts additional payloads from a remote server, establishes persistence through Windows registry modifications, and runs silently in the background with no user interface. This downloader has been observed masquerading as "MicrosoftUpdateOneDrive" to appear legitimate while setting up multiple autorun entries to execute the core components of STOCKSTAY.
.NET AppDomainManager
During our analysis, GTIG identified what we believe to be an early development sample of STOCKSTAY.MARKETMAKER which, instead of downloading the required components, was dependent on external mechanisms (such as .NET AppDomainManager injection) for the initial deployment of samples to the target host.
STOCKSTAY Server-Side Controller
GTIG identified a publicly accessible GitHub repository containing a Python implementation of the victim-facing STOCKSTAY WebSocket server controller. The lightweight design of the server component appears to supplement the threat actor’s usage of third-party hosting platforms such as Render platform which provides a platform for hosting web services, including WebSockets. The inability for the server to decrypt inbound messages prevents introspection by platform operators, and further obfuscates the location of the threat actor’s dedicated infrastructure. This architecture somewhat resembles Turla’s multi-hop KAZUAR C2 infrastructure.
Figure 4: Overview of STOCKSTAY C2 Infrastructure
The server extends tornado.websocket.WebSocketHandler to provide the interface described in Table 2, under the path /ws; aligning with all observed STOCKSTAY WebSocket C2 URLs.
| Event | Description |
| WebSocketHandler.check_origin | Hard-coded to return True to accept all cross-origin traffic. |
| WebSocketHandler.open | Logs the client’s IP address using the following string format:
|
| WebSocketHandler.on_message | Handles inbound messages from the connected client. Inbound messages are base64-decoded before being parsed as JSON into an object internally known as a “package”. Each “package” contains an “action” and a “container”, which provide the request’s type and associated data, respectively. The following describes the handling logic of each action type. Action: send The server extracts the following attributes from the inbound message’s “container” and inserts them into a new row within the local
On completion, the server logs the following message:
Action: recv Inbound The server then retrieves all messages from the Each matching row is returned to the client in the following format, before being deleted from the database. On completion, the server logs the following message:
|
| WebSocketHandler.on_close | Logs the client’s IP address using the following string format:
|
Table 2: Overview of STOCKSTAY WebSocket Server Interface
Database Structure
The server maintains a local SQLite3 database under the filename weather_data1.db, structured as shown in Tables 3 and 4.
| Column | Description |
|---|---|
|
| Primary key |
|
| Recipient's UUID from |
|
| Sender's UUID from |
|
| Message data from |
|
| Sender's IP address, extracted from |
|
| Defaults to 0 - doesn't appear to be used or returned to the client. |
|
| Time of row creation |
Table 3: weather_data database table structure
| Column | Description |
|---|---|
|
| Primary key |
|
| Log message |
|
| Time of creation |
Table 4: log database table structure
Key Operational Characteristics
Consistent Use of Academic or Diplomatic Lure Content
The threat actor(s) involved in STOCKSTAY operations appear to have an affinity for integrating academia and diplomacy into their infrastructure and lure/decoy content, including:
-
compromising an email account belonging to a Ukrainian university to disseminate phishing emails;
-
using the names of an academic institution within the file name of a malicious RDP file;
-
compromising a diplomatic education platform for phishing and distribution of malicious RDP files;
-
using “education” and “diplo” within registered phishing domains; and
-
using “DiplomacyEduAI” as the product name within STOCKSTAY MSI files.
Persistent Ukrainian Targeting
A significant proportion of STOCKSTAY operations observed by GTIG have been targeted at Government or Military organizations within Ukraine, consistent with Russian interests in relation to the ongoing conflict between the two countries. The threat actor has been observed utilizing in-country compromised infrastructure, including compromised government services, to deploy both STOCKSTAY and a range of supplementary payloads, in support of these operations.
Suspected European Targeting
A smaller number of STOCKSTAY operations observed by GTIG appear to have been targeted at European entities. Early development samples of STOCKSTAY were identified in various European nations, including Italy, the Netherlands, Poland, and Germany; however, we have been largely unable to confirm the intended victims for the majority of these early infections, nor whether these samples were identified as a result of the threat actor testing their capabilities against publicly available virus scanning services such as VirusTotal. GTIG was able to identify, in at least one case, the targeting of entities associated with, or interested in, a foreign affairs ministry in Europe in relation to phishing and suspected STOCKSTAY activity.
Deployment via Malicious RDP Files
GTIG observed STOCKSTAY being deployed following successful phishing attempts using malicious RDP configuration files. The RDP files were designed to create a connection from the victim’s device to actor-controlled infrastructure, through which the actor could then deploy subsequent payloads.
In one operation in early 2025, GTIG identified a phishing email, claiming to be sent by a defense-related training academy, containing a malicious RDP file attachment. A short time following the victim’s connection to the actor’s infrastructure, the actor deployed STOCKSTAY.MARKETMAKER, a .NET downloader designed to retrieve and install the full STOCKSTAY suite on the victim’s device.
Later, in mid-2025, GTIG identified similar malicious RDP files being hosted on a compromised diplomatic-themed education platform, luring victims into downloading and executing the file under the guise of enabling access to an online training portal. GTIG was unable to confirm whether STOCKSTAY was ultimately deployed as a result of this operation; however, overlaps in the actor’s infrastructure and education-themed lures for both operations may suggest STOCKSTAY was the intended payload.
Deployments at Multiple Stages of Operations
Through GTIG’s visibility, we have identified that the threat actor uses STOCKSTAY at multiple distinct stages of their operations.
In the first instance, the threat actor uses STOCKSTAY during operations to gain initial access into environments which haven’t yet been subject to the group’s reconnaissance activities. In these instances, STOCKSTAY is configured with hard-coded configuration passwords, which can be trivially extracted by analysts. We observed this type of infection stemming from the group’s phishing operations, where the threat actor is unable to determine exactly where in the victim’s network they are going to gain their initial foothold.
When the threat actor deploys STOCKSTAY at a later stage of operation, following reconnaissance, STOCKSTAY is configured to incorporate environmental keying for its configuration, requiring the malware to be executed either on a specific host, by a specific user, within a specific domain, or a pre-determined combination of the these attributes. This configuration implies that, at this stage, the actor knows exactly which machine is being targeted, likely through existing accesses to the target environment. This was seen within Ukrainian networks where STOCKSTAY was deployed toward the end of an operation which had previously relied heavily on the group’s other tools, such as KAZUAR.
Overlaps with KAZUAR
K1MORPHER String Obfuscation
In April 2025, GTIG observed STOCKSTAY being updated to implement a new string obfuscation mechanism, based around an obscure pseudo-random number generation algorithm named “Squirrel3”, which was presented at Game Developers Conference 2017.
GTIG later identified versions of STOCKSTAY containing some of their original class-names, which showed the code responsible for runtime string deobfuscation being contained within a class named “K1.Morpher”. Analysis of K1MORPHER shows the ability to perform runtime deobfuscation of a range of datatypes, such as strings, integers, and arrays.
In June 2025 GTIG noticed K1MORPHER code appearing in samples of KAZUAR. KAZUAR has historically used its own simple but effective code and string obfuscation techniques to evade detection, such as: the insertion of junk code; replacing static constant values with the results of XOR operations; and large quantities of unique character substitution tables. The actor’s use of K1MORPHER within STOCKSTAY appears to be trending toward mimicking KAZUAR’s multi-class obfuscation techniques, where obfuscation is handled by multiple distinct classes, as observed in suspected test builds of STOCKSTAY hosted on a compromised Cypriot website in April 2024.
Implant Architecture
Since at least 2024, KAZUAR has been observed being deployed using a multi-component architecture, whereby C2 communication, task orchestration, and task execution are managed by separate components. Within the KAZUAR ecosystem, these components are referred to as “BRIDGE”, “KERNEL”, and “WORKER”, respectively.
As of late 2023, GTIG identified a similar separation of responsibilities within the STOCKSTAY ecosystem, with the same responsibilities being separated into distinct components. C2 communication is managed by the component tracked by GTIG as STOCKSTAY.STOCKBROKER, while task orchestration and execution are handled by STOCKSTAY.STOCKMARKET and STOCKSTAY.STOCKTRADER, respectively.
Environmental Keying
Both KAZUAR and STOCKSTAY ecosystems have been observed using environmental keying to protect themselves from detection and analysis.
DIAMONDBACK, a dropper often deployed prior to KAZUAR in the execution chain, has made use of a hash of the target’s hostname in decrypting its payload, to prevent divulgence of its intentions outside of the target environment. Later versions of DIAMONDBACK can be configured to incorporate the target’s username and domain name in the hash required to decryp
