ScreenConnect Turned Loader: Trojanized Installers Push AsyncRAT via Spoofed Software Sites
A sprawling campaign is abusing a signed RMM binary to sideload AsyncRAT onto victims chasing free copies of OBS Studio, Bandicam, and other utilities, Kaspersky says.
Key points
- Attackers embed a preconfigured ScreenConnect agent inside fake software installers to establish an interactive foothold before deploying AsyncRAT.
- Spoofed download pages impersonate OBS Studio, DNS Jumper, DS4Windows, and Bandicam, reached via SEO poisoning and malvertising.
- The ScreenConnect binary is legitimately signed, so code-signing checks and reputation-based AV will typically pass it.
- Detection must happen at the behavioral layer, not the signature layer.
- No CVE is involved: the abuse is entirely procedural.
What is actually happening here?
Kaspersky describes a "massive, multi-domain, multi-language" operation that hosts malicious installer archives on spoofed software sites. Victims pull down a working copy of the advertised app alongside a preconfigured ScreenConnect agent that phones home to attacker-controlled relay infrastructure. Once the RMM client (remote-management tool) checks in, the operator has file transfer and command execution without dropping a custom implant during initial access. AsyncRAT arrives in a follow-on stage, adding keylogging, credential theft, and plugin support.
The technique borrows from a familiar playbook. Our 4 June report on lookalike open-source portals tracked a comparable SEO-climbing delivery chain, and the RMM-as-initial-access angle appeared in our 23 June coverage of VBScript loaders spreading via WhatsApp. What distinguishes this campaign is scale: the sheer number of lure brands and lookalike domains points to affiliate-style infrastructure rather than a single operator running a one-off kit.
Should you worry about the signed binary?
Yes, and that is precisely the problem. Because ConnectWise signs the ScreenConnect client, most endpoint controls treat it as trusted. Detection has to happen at the behavioral layer: watch for ScreenConnect.ClientService.exe executing on endpoints that were never enrolled in a sanctioned RMM tenant, outbound TLS to relay hostnames your MSP doesn't own, and instance GUIDs that don't match your known deployment.
Blocking is messier than it sounds. Denylisting the binary breaks legitimate MSP workflows. Application allowlisting scoped to your sanctioned tenant ID, enforced through WDAC or an EDR policy, is the cleaner path. ConnectWise publishes guidance on locking down client configuration in its trust center.
How do you hunt for this?
AsyncRAT is open-source (the original repo has been forked extensively), so signature-based IOCs age out fast. Hunt instead on parent-child process chains where an installer MSI or NSIS package spawns ScreenConnect.ClientSetup.exe from %TEMP% or %APPDATA%, followed by outbound traffic to *.screenconnect.com subdomains you don't recognise.
Users pulling installers from search-ad results remain the reliable weak link. If your endpoint policy still permits arbitrary MSI execution from user-writable directories, this campaign is a fair prompt to revisit that. No CVE, no zero-day: just a signed binary, a search engine, and a patient adversary willing to run the numbers across dozens of domains until something lands.
