New Russian Campaign Uses Fake Webex and Zoom Installers to Deploy Starland RAT

Pierluigi Paganini
July 17, 2026

Russian-speaking UAT-11795 spreads trojanized Zoom, Webex, and MobaXterm installers to deliver Starland RAT and the WLDR memory-only implant.

Cisco Talos researchers published a detailed technical report on July 16 disclosing UAT-11795, a financially motivated, Russian-speaking threat actor that has been running a malware campaign against users in the United States and Europe since at least June 2025. The operation distributes trojanized installers for software that IT professionals and developers actually use: MobaXterm, Cisco Webex, Zoom, DBeaver, and even the gaming platform FACEIT.

“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.” reads the report published by Talos.

The wide range of targets, from developer tools and business collaboration software to gaming platforms, suggests the attackers are trying to infect many different types of users instead of focusing on a single industry.

The campaign delivers two newly documented malware families. The first is Starland RAT, a Python-based remote access tool with credential theft and cryptocurrency wallet enumeration built in. The second is the WLDR agent, a PowerShell-based command-and-control implant that runs entirely in memory. Both are novel. Talos also observed the actor deploying CastleStealer and Remcos RAT as additional payloads delivered through Starland after initial compromise.

Initial access appears to come through a ClickFix social engineering technique, where the victim is tricked into running a command that downloads and executes a malicious HTA file silently. That HTA file drops a Windows batch file and a trojanized installer, while simultaneously establishing persistence through a registry Run key that re-executes the HTA every time the user logs in. A Russian-language developer comment found inside the VBScript, “Добавление команды в автозапуск для текущего пользователя,” confirms the actors are Russian-speaking and, apparently, left their development notes in the deployed code.

The trojanized installers are built using the Nullsoft Scriptable Install System. They package a real Python runtime alongside a compiled Python loader disguised as a file named LICENSE.txt. The NSIS script executes the loader, which decrypts Starland RAT using a single-byte XOR key and runs it directly in memory. The actual software installation proceeds normally, so the victim sees what they expected and has no reason to suspect anything happened.

Before any network activity, Starland checks whether it’s running in a sandbox. It compares the logged-on username against a hardcoded list of known sandbox service accounts including WDAGUtilityAccount, then checks the computer name against hostnames from Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. It also checks for a Zone.Identifier alternate data stream on the installer file to confirm it was downloaded through a browser rather than dropped directly. Any mismatch terminates execution.

“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.” continues the report. “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.”

After clearing those checks, the RAT establishes persistence before making any network calls, creating a scheduled task with a randomized name following the pattern PythonLauncher-{3 random characters} and a Startup folder shortcut as a secondary mechanism. It then runs reconnaissance: hardware ID derived from the C: drive volume serial number, total RAM, installed antivirus, and Active Directory membership. If the machine is domain-joined, it executes whoami, systeminfo, net user, and nltest to map the domain structure. It also enumerates over 40 cryptocurrency wallets from both browser extensions and desktop applications, takes a screenshot of the desktop, and bundles everything into a JSON payload that it XOR-encrypts with the key “helo1” before sending it to the C2.

The C2 design is worth calling out. The RAT sends victim registration data to a hardcoded primary C2 domain, but if that fails, it uses a Polygon Ethereum smart contract as a backup.

“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.” states Talos. “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.”

Blocking a C2 domain doesn’t help if the fallback address lives on a public blockchain that you can’t take down.

Before registering with the C2, the RAT sends a Telegram notification to an attacker-controlled bot with the victim’s public IP, OS details, processor information, computer name presented as a “Crew ID,” and any detected cryptocurrency wallets. Two Telegram bots are used: “skuefq_bot” and “komandastuk_bot.” Talos also found a private Telegram channel called “stuk komanda” created June 5, 2025, structured like a C2 dashboard, confirming the operation’s timeline.

When Starland receives a shellexecute command from the C2, the actor can use it to deploy the WLDR framework. This arrives in three stages: a heavily obfuscated PowerShell stager, a downloader that fetches victim-specific payloads bound to the machine’s hardware ID, and the WLDR agent itself, which runs entirely in memory.

“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.” continues the report.

The WLDR agent uses AES-256-CBC with HMAC-SHA256 for all communication, derives session keys through PBKDF2-SHA256 at 5,000 iterations, and masks its traffic with headers that mimic a Chrome 124 browser session. The Runspace engine supports up to 10 concurrent threads and streams output back to the C2 in real time as scripts execute rather than waiting for completion, making it suitable for interactive monitoring tasks. The C2 responds only to requests that carry a matching hardware ID, so probing the endpoint directly returns nothing useful.

Starland also delivers CastleStealer, a .NET infostealer that targets browser credentials across the full Chromium family and Firefox, cryptocurrency wallet extensions, Discord and Telegram session files, and Steam credentials. It checks for a Russian locale and exits if it matches, which is consistent with the operator protecting their own environment. Remcos RAT is delivered through a separate 32-bit shellcode path. The custom shellcode loader that handles both payloads disables AMSI and ETW at runtime by patching the first bytes of AmsiScanBuffer and EtwEventWrite in memory, then falls back to a VirtualProtect-based write if the primary patching fails, before decompressing and injecting the final payload using reflective PE injection or .NET CLR loading depending on the payload type.

The full indicator set including domains, IPs, file hashes, and Snort rule IDs is available in Talos’ GitHub repository linked from the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon