UAT-11795 deploys novel Starland RAT and bespoke WLDR C2 implant in financially motivated campaign

• 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.