ScreenConnect Abused via Rogue Clients: Four-Stage VBScript Chain Worms Newly Connected Hosts

Huntress discloses three ScreenConnect abuse incidents: a four-stage VBScript chain re-infects hosts on each new connection. ConnectWise confirms a file-transfer flaw; disable TransferFiles pending a fix.

Huntress disclosed three attacks abusing ConnectWise ScreenConnect: attackers installed malicious clients pointing at attacker infrastructure via different social-engineering entry points, then ran a four-stage VBScript chain. They abused ScreenConnect's own file-transfer behavior to re-infect the technician-side host on every new connection — worm-like spread. ConnectWise confirmed the flaw; official fix and CVE ID not yet published.

Incident overview

Three independent incidents in August, distinct initial access: one tech-support scam inducing the user to run Microsoft Quick Assist; one phishing email delivering ScreenConnect.ClientSetup.msi; one fake Geek Squad refund page inducing a client download. All three ended the same way — a malicious ScreenConnect client pointing at attacker C2, then wscript.exe executing 1.vbs through 4.vbs in sequence.

Technical details

The four VBScripts form a state machine:

• 1.vbs: recon. Checks RAM > 5GB, whether ScreenConnect is installed, presence of Cisco AMP, CrowdStrike, SentinelOne, Sophos, etc. Encodes results as a three-digit state value in a temp file.
• 2.vbs: waits for the state file, then pulls config from Dropbox.
• 3.vbs: downloads the matching encrypted payload based on the state value.
• 4.vbs: decrypts the payload via a PowerShell script and runs stage two.

State values pick the payload: 000/001 install a user-level ScreenConnect backdoor; 010 deploys UAC bypass and persistence; 011 disables Microsoft Defender reporting and memory integrity, then runs XMRig.

The worm mechanism is the part to watch: the infected client replays the full VBScript chain on every new Host connection, infecting the technician-side machine. The client records attacked ConnectionIDs but clears that record on disconnect; reconnect retriggers infection. Known C2: 45.13.237.190 (tele-sync.opik.net), 131.123.40.98:8041, borertors92.anondns.net. Persistence: Run key pointing at WindowsServiceHost.vbs under AppData.

Impact

• Flaw is in ScreenConnect remote-access Support and Access session file-transfer behavior. Cloud and on-prem both affected.
• ConnectWise says CVE ID and official fix expected this week; exposure window remains until then.
• RMM tools are widely used for remote ops; abuse gives attackers a trusted remote-management channel for free.

Remediation

• Immediately disable TransferFiles for all technician roles under Administration > Security > Roles (older builds: TransferFilesInSession). Official temporary mitigation.
• Hunt: wscript.exe executing numbered VBS files from a ScreenConnect path, WindowsServiceHost Run key, the C2 domains and IPs above.
• Confirmed-infected hosts: do not attempt manual cleanup — layered persistence plus worm re-infection. Huntress recommends reimage from trusted media.
• Least-privilege RMM: file transfer, script execution, and other high-risk permissions off by default, on by need.

References

• The Hacker News：Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain
• Cybersecurity Beat：Tech support scams turn ScreenConnect into a worm