This backdoor is named after your VMware and EDR tools. Your allowlist trusts it.

The fastest way past a security team is to look like the software that team already trusts. A Chinese-speaking espionage group has built its current campaign on that single idea. Its tools land on disk wearing the names of VMware utilities, an endpoint security agent, and a Microsoft developer process. Palo Alto Networks Unit 42 documented the group this week, after tracking it breaking into at least ten government and energy organizations across Southeast Asia between October and December 2025. The espionage is routine for a state actor. The naming is the part worth your attention.

Unit 42 tracks the cluster as CL-STA-1062 and ties it to operations going back to March 2022, with overlaps to activity Cisco Talos reported against Taiwanese web hosting providers in 2025 under the label UAT-7237. Security Affairs, reporting the same findings, notes the group shifted its focus to Southeast Asian state-owned energy and government networks in mid-2025. What makes the campaign useful to study is not where it struck. It is a tradecraft choice that works against almost any defender, including ones this group will never target.

The names are picked to land in your blind spot

Every file the group drops is named after something a security analyst is trained to ignore. The custom backdoor runs as PerfWatson2.exe, the name of a real Microsoft Visual Studio telemetry helper. Its tunneling tools, SoftEther VPN and two open-source proxies called Yuze and VNT, are renamed to look like VMware components such as vmtools.exe or like endpoint detection and response agents. Persistence is a scheduled task dressed up as a Google updater.

This is not generic stealth. Virtualization helpers and security agents are exactly the processes a SOC tunes out of its alerts, because they are noisy, signed, and everywhere. Naming malware after them is choosing the one category of process most likely to be on an allowlist and least likely to draw a second look. It is the same blind spot a fake Node.js runtime exploited in hotels recently. The group is not hiding from your tools. It is hiding inside your assumptions about them.

A signed installer is no longer a character reference

The delivery method makes the same bet in a different place. The backdoor arrives inside an archive named chrome_setup.zip that holds three things: a legitimate, validly signed executable, a configuration file, and a malicious library called MyAppDomainManager.dll. When the signed program starts, the .NET runtime reads the configuration, loads the attacker's library through a technique called AppDomainManager injection, and the backdoor runs inside a trusted, signed process.

That defeats two common heuristics at once. A filename allowlist passes, because the running binary is genuinely Microsoft-signed. A parent-process reputation check passes for the same reason. "It came from a signed binary" tells you nothing here, because the malicious code never needed its own signature. It rode in on a config file sitting next to one. If your detection logic treats a signed parent as a reason to relax, this is the case it was built to slip through. AppDomainManager injection maps to MITRE ATT&CK technique T1574.014, and it deserves a hunt rule of its own.

What TinyRCT does once it lands

The payload, which Unit 42 named TinyRCT, is a compact backdoor written in C# and previously undocumented. It only runs from the user's %LOCALAPPDATA% folder and quits anywhere else, a cheap anti-analysis check that also keeps it out of the paths defenders scan first. It calls home to a hardcoded command server at 45.32.113.172 every ten seconds over plain HTTP, encrypting its traffic with AES using a key baked into the binary. From there it runs commands through cmd.exe, lists and steals files in compressed encrypted chunks, captures screenshots, pulls down more tools, and deletes itself on command.

The rest of the toolkit is borrowed: Mimikatz and JuicyPotato for credentials and privilege escalation, ASPX web shells for the initial foothold on internet-facing web applications, and Microsoft SQL Server as a target for bulk data theft. A second staging server at 139.180.134.221 fed extra payloads. None of that is new on its own. The custom backdoor and the disciplined masquerade are what move this group up a tier.

Does this matter if you are not in Southeast Asia?

Yes. The victims here are regional, but the technique is portable and already common. Any organization that allowlists by filename, or treats a signed parent process as trusted, is exposed to this exact playbook whether or not CL-STA-1062 ever points at it. The defensive lesson travels even when the actor does not.

Hunt the behavior, because the names will change

Renaming a binary is free, and recompiling one to break a hash is nearly free. So the file names and hashes in Unit 42's report will rot fast. The constants this group reuses are the durable signal, and they work in your favor: a fixed ten-second check-in interval, traffic to the same two servers, binaries that refuse to run outside %LOCALAPPDATA%, and a .NET configuration file sitting beside a signed executable. Those survive the recompiles that defeat signatures.

Three things belong in your detection plan now. Alert on regular, fixed-interval outbound connections, the call-home pattern, rather than on specific addresses. Flag processes that run from %LOCALAPPDATA% while carrying the name of a system or security tool, because the real ones do not live there. And hunt for AppDomainManager configuration files planted next to signed binaries. This is the same shape we have written about in Turla's redundant backdoors and Velvet Ant's auth-stack implants: a custom tool, living-off-the-land utilities, and a costume. The escalation this time is that the costume is your security stack itself. A managed detection program earns its keep right here, by alerting on how a process behaves rather than what it claims to be.