A threat actor tracked as CL-STA-1062 has been linked to a new custom backdoor called TinyRCT, deployed against government entities and state-owned energy and critical-infrastructure organizations across Southeast Asia. Palo Alto Networks Unit 42 published the findings on June 26, 2026, per The Hacker News, and noted overlaps between CL-STA-1062 and UAT-7237, a group Cisco Talos first flagged in August 2025 over a campaign against Taiwanese web infrastructure. Unit 42 traced CL-STA-1062 activity in the region back to at least March 2022 — a sustained, multi-year operation rather than a single incident.

The initial break-in in this campaign did not come through a phishing email. CL-STA-1062 got in by scanning internet-facing web applications for vulnerabilities and planting ASPX web shells — a server-side foothold used for reconnaissance and outbound calls to attacker infrastructure before further payloads were dropped. That is worth stating plainly, because it means no inbox filter, no matter how good, would have stopped this particular intrusion at the front door. What the campaign does show, though, is a payload-delivery and lateral-movement playbook — masqueraded installers, DLL sideloading, encrypted archives, and data staged for exfiltration — that recurs constantly in the email-delivered version of the same kind of attack, and that is exactly the layer Sorb Security’s Cloud Email Security (SCES) platform is built to catch.

What Unit 42 Found: TinyRCT and the CL-STA-1062 Toolkit

Unit 42 describes CL-STA-1062 as relying on a hybrid toolkit: common open-source tools including SoftEther VPN, Mimikatz, and VNT for lateral movement and credential access, alongside a bespoke backdoor the researchers had not previously documented. TinyRCT (observed on disk as “PerfWatson2.exe”) can run arbitrary commands, enumerate and exfiltrate files, capture the screen, and take remote control of the host — and it deletes itself from the compromised machine and takes steps to avoid executing inside sandboxed analysis environments. It communicates with a command-and-control server over HTTP, encrypting the traffic with AES-128 in CBC mode, and beacons out on a default 10-second interval — polling for instructions with GET requests and sending stolen data back over POST.

In one campaign detected in September 2025, the group infiltrated a Southeast Asian government entity, planted a web shell, and exfiltrated data from an MS SQL server — including, in one case, an entire directory of the organization’s web server source code. During the same operation, the actors also conducted network reconnaissance against a separate government entity in the same country, suggesting an effort to widen access beyond the initial target. Unit 42 says it identified at least 10 different organizations breached across the region between October and December 2025 alone.

The Delivery Trick: A Legitimate-Looking Chrome Installer Hiding a DLL Sideload

TinyRCT reaches the host through a malicious archive named chrome_setup.zip, which bundles a legitimate executable (chrome_setup.exe), a configuration file, and a rogue DLL named MyAppDomainManager.dll. That DLL triggers an AppDomainManager injection attack (MITRE ATT&CK T1574.014) — a technique that abuses a legitimate .NET application-loading mechanism to run attacker code without dropping an obviously malicious binary. The DLL then acts as a downloader, reaching out to a second attacker-controlled server to retrieve the actual TinyRCT payload. Elsewhere in the campaign, the group’s SoftEther VPN components and utilities like Yuze (a SOCKS5 proxy) and VNT were found disguised as VMware executables or endpoint security agents — file names like XDRAgent.exe, vmtools.exe, and vmwared.exe — specifically to blend in with software an IT or security team would expect to see running.

Where Email Fits a Campaign That Didn’t Start With Phishing

It’s tempting for any email security vendor to stretch a story like this one to fit its own product — that would be dishonest here, since the recorded initial access vector is web-application exploitation, not a phishing message. But two things about this campaign are directly relevant to the mailbox layer regardless. First, the delivery mechanism — a ZIP archive containing a masqueraded installer and a sideloaded DLL — is one of the single most common patterns used when this same class of actor does deliver a payload by email, whether as a secondary stage to reach staff outside the compromised web application’s direct control, or when a harder-to-exploit target forces a pivot to spear-phishing instead. Second, once an attacker has staged and exfiltrated an entire directory of source code from one breached entity and is actively scanning a second one, the follow-on activity — spreading to new targets, moving data out, impersonating a trusted contact at the first victim to reach the second — is exactly the pattern that email-layer anomaly detection and outbound monitoring exist to catch, independent of how the attacker got their first foothold.

How Sorb’s SCES Platform Would Catch the Email-Borne Version of This Attack

A masqueraded, ZIP-wrapped installer never gets the chance to sideload. Sorb’s Attachment Engine extracts and cracks encrypted or password-protected archives before the antivirus check runs, and separately extracts hyperlinks and embedded executables from within attachments — closing the exact hiding spot a chrome_setup.zip-style payload depends on. A dual-AV, dual-sandbox architecture then detonates the contents twice through independent engines rather than relying on a single static scan.

Previously undocumented backdoors don’t get a free pass from signature matching. TinyRCT was, by Unit 42’s own account, a backdoor nobody had documented before this report — meaning no antivirus vendor had a signature for it on day one. Sorb’s Advanced Threat Protection and Sorb Cloud Sandbox are built specifically for that gap: real-time dynamic malware analysis designed to catch payloads that traditional signature- and reputation-based tools miss, including malware built to detect and evade sandboxed analysis, which is precisely the evasion behavior Unit 42 observed in TinyRCT.

A masqueraded binary calling home never gets to execute on the endpoint. If a link to the second-stage payload is shared or clicked through email, Sorb’s Zero Trust URL Engine rewrites and re-evaluates the link at click-time and can route the session through browser air-gapping, isolating the web content from the user’s device so a downloader DLL never gets a chance to reach attacker infrastructure directly from the endpoint.

Data staged for exfiltration doesn’t leave quietly through the mail server. Unit 42 documented the group exfiltrating an entire source-code directory from one victim. Sorb’s Outbound Filtering and Data Leak Protection scan outbound mail for sensitive or anomalous content and enforce policy-driven encryption, giving a security team a chance to catch large or unusual data leaving through corporate email or webmail, which is a common secondary exfiltration channel once an attacker already has a network foothold.

Lateral spread to a second target gets flagged, not assumed. Unit 42 noted the group conducting reconnaissance against a separate government entity in the same country during the same operation. If that expansion is attempted through a spoofed or compromised sender identity, Sorb’s BEC protection suite traces sender-authentication and signature anomalies against mail history and triggers an alert — rather than waiting for the second organization to discover the intrusion the way the first one did.

Frequently Asked Questions

Did this attack actually start with a phishing email?

No. Unit 42’s report attributes CL-STA-1062’s initial access to scanning internet-facing web applications for vulnerabilities and deploying ASPX web shells — a server-side compromise, not an email-based one. Any framing that implies otherwise would misrepresent the reporting.

If this wasn’t a phishing attack, why does an email security product matter here?

Because the techniques used after the initial break-in — a masqueraded ZIP installer, DLL sideloading via AppDomainManager injection, disguised binaries, staged data exfiltration, and reconnaissance against a second organization — are the same techniques the same class of actor commonly delivers by email when a target’s web-facing surface is better hardened, or when spreading from an already-compromised entity to a new one. Email defense is a complementary layer for that stage of the kill chain, not a claim that it would have stopped this specific intrusion’s front door.

What is AppDomainManager injection, and can email security stop it?

It’s a technique (MITRE ATT&CK T1574.014) that abuses a legitimate .NET mechanism for loading application configuration to run attacker-supplied code instead, without dropping an obviously malicious executable. Email security can’t stop the technique itself once it’s running on a host — what it can do is stop the disguised ZIP archive and sideloaded DLL from ever reaching the endpoint in the first place, by extracting and detonating archive contents before delivery and re-checking any related links at click-time.

What should government and critical-infrastructure IT teams do right now?

Patch and monitor internet-facing web applications for the ASPX web-shell activity Unit 42 describes, watch for outbound HTTP beaconing on short, regular intervals to unfamiliar IPs (Unit 42 observed a 10-second default), and treat any installer-named ZIP archive — especially one masquerading as common software like Chrome, VMware, or an XDR/EDR agent — as a high-risk attachment category regardless of which channel it arrives through.