Rogue ScreenConnect Installations: Worm-Like VBScript Propagation Over Remote Support Sessions

An investigation into three incidents at unrelated organizations identified the same pattern: rogue ScreenConnect clients repeatedly spawning Windows Script Host to execute four numbered VBScript files. Initial access relied on social engineering, including tech-support scams, phishing, and fake refund workflows that convinced victims to install attacker-controlled ScreenConnect clients. The rogue clients connected to attacker infrastructure using bare IP addresses, non-standard ports, or dynamic DNS domains, and some incidents also involved secondary remote access tooling.

The four-stage VBScript loader profiles the host before selecting a payload. The first stage records whether ScreenConnect is already installed, whether third-party endpoint protection is present or Defender is the only active product, and whether the system has more than 5 GB of memory, which also serves as an analysis-environment check. Later stages retrieve and decode a payload catalog, select the package matching that host profile, download the encrypted archive, and build a PowerShell stager that decrypts and executes it from the user profile. The chain cleans up its temporary files afterward, while persistence is established through a user Run key that launches a VBScript-backed batch file.

Delivered payloads vary by profile and include a concealed ScreenConnect backdoor, privilege-escalation and persistence tooling, tunneling utilities, and a cryptocurrency miner. The escalation branch abuses the `ms-settings` protocol handler and `ComputerDefaults.exe` for UAC bypass, then uses elevated PowerShell to weaken security controls, add broad Defender exclusions, prevent sleep and hibernation, and install an additional hidden ScreenConnect service. Other branches disable Defender and HVCI-related protections, establish an attacker tunnel, deploy an XMRig miner, and drop a vulnerable kernel driver.

The most significant capability is cross-organization propagation. Modified ScreenConnect clients monitor newly established remote support sessions, register the four VBScript files with ScreenConnect's own file-transfer mechanism, and queue them for execution on the connecting technician's system. This allows an infected endpoint to deliver the same loader to helpdesk or support systems that connect to it, creating worm-like spread between otherwise unrelated organizations. ConnectWise attributed this behavior to CVE-2026-84869, a client-side authorization flaw affecting Support and Access sessions that could allow file transfers and execution without proper host confirmation. Server installations are not affected, and the issue was fixed in ScreenConnect 26.6.5.