Since June 2025, Russian threat actor UAT‑11795 has been delivering the Starland RAT via trojanized installers for popular tools like WebEx and Zoom, according to Cisco Talos and the original report. That’s the catch: the malware masquerades as legitimate software, and it’s been targeting users in the United States, Germany, Romania, and Venezuela.
Key Takeaways
- UAT‑11795 distributes a new backdoor called Starland RAT through trojanized installers for WebEx, Zoom, MobaXterm, DBeaver, and FaceIT.
- The infection chain starts with an HTA file that drops a disguised NSIS installer and a Python loader hidden as
LICENSE.txt. - Starland RAT harvests browser data, cryptocurrency wallets (over 40 wallets), AD details, and system hardware info.
- It delivers CastleStealer and Remcos as secondary payloads, and its C2 includes a Polygon smart‑contract fallback.
- Defenders should apply the IoCs from Cisco Talos and enforce strict download‑only‑from‑official‑source policies.
Historical Context
The technique of bundling malware with legitimate‑looking installers isn’t new. Earlier in the decade, threat actors used similar methods to spread ransomware through compromised software distribution channels. Those campaigns relied on unsigned binaries or weak code‑signing practices, which gave attackers a foothold in corporate environments. Over time, defenders grew more accustomed to checking digital signatures and verifying hash values before deployment.
What changed with Starland is the use of an HTA dropper that pulls an NSIS package, coupled with a Python loader masquerading as a LICENSE.txt file. That layered approach reflects a shift toward multi‑stage payloads that can evade static analysis. The actor also introduced a blockchain‑based fallback for command‑and‑control, a move that mirrors trends seen in other financially motivated malware families.
Since the first sightings in mid‑2025, security researchers have traced the campaign across multiple continents. The spread aligns with a broader increase in attacks targeting collaboration tools, which saw a surge in usage after the pandemic. Attackers know that users trust these platforms and often grant them elevated permissions. That trust becomes an easy lever for malicious actors.
Starland RAT Campaign Targets WebEx, Zoom
Researchers at Cisco Talos say the actor’s approach is both broad and precise. They’ve seen trojanized installers for WebEx and Zoom that look identical to the official packages, yet they embed the malicious payload. The threat actor hasn’t confirmed the exact delivery vector, but they speculate the files are likely pushed using the ClickFix method—an approach that exploits trusted software updates to slip malware onto a victim’s machine.
That speculation matters because ClickFix can bypass many “only install signed code” safeguards. If the attacker can convince a user that the installer is legitimate, the user’s trust does the heavy lifting. It’s a reminder that social engineering remains a frontline tactic, even against enterprise‑grade tools.
How the Attack Chain Unfolds
Initial Drop and Loader
The chain begins with an HTA (HTML Application) file that silently pulls a trojanized NSIS installer. Inside, the attacker hides a Python loader disguised as a plain‑text LICENSE.txt file. That loader edits the Windows Registry to cement persistence, then decrypts the core Starland RAT binary before launching it.
That’s a clever trick. By using a familiar filename, the loader avoids raising suspicion, and the registry tweak ensures the RAT survives reboots. The decryption step also means analysts can’t simply hash‑compare the binary to known samples without first unpacking it.
Persistence and Privilege Escalation
Once on the system, Starland checks for sandbox environments, adds scheduled tasks, and drops shortcuts into the Startup folder. It also attempts to raise its privileges, hunting for misconfigurations in the local security token. If it succeeds, the malware gains the same rights as the logged‑in user, which is often enough to skim credentials and wallet files.
We’ve seen that kind of behavior before, but the fact that it combines both 32‑bit and 64‑bit shellcode chains makes it harder to block with a single signature. The 64‑bit chain delivers CastleStealer, while the 32‑bit chain drops Remcos RAT.
What Starland RAT Steals
Starland RAT is a data‑harvesting machine. It looks for three broad categories of information on the compromised host:
- Browser data and cryptocurrency wallets – covering more than 40 desktop and browser‑extension wallets.
- System details – HWID, RAM, processor, OS version, computer name, region, public IP, and installed antivirus products.
- Active Directory info – domain structure, domain controllers, and the victim’s domain privileges.
Beyond that, the RAT can capture screenshots, execute arbitrary shell commands, inject 32‑ or 64‑bit shellcode, and pull additional payloads such as EXEs, MSIs, DLLs, or ZIP archives. That breadth means a single infection can turn a workstation into a multi‑purpose espionage platform.
Payloads Riding on Starland: CastleStealer and Remcos
The 64‑bit shellcode chain drops CastleStealer, an info‑stealer focused on browser credentials, crypto wallet data, Discord and Telegram sessions, Steam credentials, and even arbitrary files on the filesystem. In other words, it’s a one‑stop shop for any personal or financial data the attacker might want to monetize.
Meanwhile, the 32‑bit chain brings in Remcos RAT, which gives the attacker classic remote‑access capabilities: keylogging, webcam and screen capture, audio recording, clipboard monitoring, file management, and remote command execution. The combination of a stealthy info‑stealer and a full‑featured remote access tool is a potent mix that can keep the adversary in the loop for weeks.
Command‑and‑Control Tricks: Smart Contract Fallback and WLDR
Cisco Talos discovered that Starland’s C2 includes a redundancy mechanism. If the hard‑coded C2 address fails, the malware queries a Polygon smart contract, using an XOR‑encrypted fallback domain to retrieve a new address. That approach sidesteps traditional domain‑blocking techniques and uses blockchain’s resilience.
Even more concerning is the use of a previously undocumented PowerShell C2 framework called WLDR. WLDR encrypts its beaconing with PBKDF2‑SHA256, runs entirely in memory, and ties payload delivery to each victim’s hardware identifier. Because it never writes to disk, standard file‑based detection struggles to spot it.
Technical Architecture and Delivery Mechanisms
From a technical standpoint, the campaign blends several well‑known components into a single delivery pipeline. The initial HTA file uses Windows’ built‑in ability to execute HTML applications without prompting the user. That HTA then invokes a URL that hosts the NSIS installer, a format familiar to many developers for packaging software.
Inside the NSIS wrapper, the Python loader is embedded as a resource. Python’s runtime is invoked via a hidden command line, allowing the loader to run even on systems without a visible console window. This stealthy execution path helps the malware avoid the typical “command prompt flashes” indicator that many users notice.
After registry modifications, the loader decrypts the Starland binary using a symmetric key that is derived from the victim’s hardware ID. This ties the payload to a single machine, preventing simple reuse of the same binary across multiple targets. The binary then spawns two separate shellcode routines—one 64‑bit, one 32‑bit—each responsible for dropping a secondary payload.
Both shellcode paths communicate with the C2 using HTTP(S) beacons. The beacons contain encrypted payload identifiers, which the server resolves to either CastleStealer or Remcos. If the primary server goes offline, the client falls back to the smart‑contract query, ensuring continuity of command.
Because the entire chain can operate without touching the disk after the initial installer, endpoint detection platforms that rely on file‑system monitoring see limited activity. Memory‑only detection, however, can still flag the anomalous PowerShell execution patterns introduced by WLDR.
Defensive Recommendations
Organizations should ingest the IoCs published in the Cisco Talos report—hashes, C2 domains, and registry keys—to feed into SIEM and EDR solutions. Users must also avoid executing commands they don’t understand and should only download software from confirmed official vendor portals.
Security teams should note that they currently log only 54% of successful attacks and alert on just 14%, leaving the majority to slip by unnoticed. That statistic underscores the need for breach‑and‑attack simulation to validate detection rules before attackers test them.
What This Means For You
If you’re a developer who ships software updates, you need to lock down your build pipeline. Any tampering with installer binaries can turn a trusted update into a delivery vehicle for Starland RAT. Implement reproducible builds and sign every artifact with a hardware‑backed key.
For founders and security leaders, the takeaway is to treat every third‑party installer as a potential attack surface. Enforce least‑privilege on workstations, monitor for unusual scheduled tasks, and keep an eye on outbound traffic to blockchain nodes—those could be the hidden C2 fallback channels the malware relies on.
Consider three concrete scenarios. First, a remote employee downloads a “WebEx” installer from a compromised internal share. The hidden HTA runs silently, and the employee’s laptop becomes a beacon for the smart‑contract C2. Second, a SaaS provider bundles a legitimate MobaXterm client with a custom installer. An attacker injects the NSIS payload, allowing them to harvest crypto wallets from developers who use the same machine for both work and personal transactions. Third, a gaming platform distributes a FaceIT client that contains the 32‑bit shellcode chain. Gamers often have weak passwords, and the Remcos RAT can harvest those credentials for resale on underground markets.
Will we see more ransomware gangs borrowing the same smart‑contract fallback technique, or will defenders develop blockchain‑aware filters that can cut off that lifeline? Only.
Key Questions Remaining
- How will security vendors adapt detection signatures to account for memory‑only payloads that never touch the disk?
- What steps can organizations take to monitor for the specific Polygon smart‑contract queries without disrupting legitimate blockchain traffic?
- Can the industry standardize reproducible builds for popular collaboration tools, reducing the risk of trojanized installers entering the supply chain?
Sources: BleepingComputer, Cisco Talos
