CYBERSECURITY researchers have disclosed worm-like activity that exploits ConnectWise ScreenConnect to push a four-stage VBScript payload to newly connected hosts. In three August 2026 incidents, attackers used distinct initial access methods—a Quick Assist tech-support scam, a phishing-delivered MSI installer, and a fake Geek Squad refund form—to deploy rogue ScreenConnect clients.
Once installed, the compromised ScreenConnect instances repeatedly spawn wscript[.]exe to run four VBScript files named 1[.]vbs, 2[.]vbs, 3[.]vbs and 4[.]vbs, enabling a multi-stage chain that culminates in further payloads.
The four stages, as observed, progress only if certain conditions are met and, depending on the host state, deliver different effects. 1[.]vbs profiles the machine, checks RAM (e.g., over 5 GB), detects ScreenConnect and installed security products, then records results in %TEMP%\\value[.]txt. 2[.]vbs waits for that file, retrieves a Dropbox payload (the URL later became unavailable), and writes map data to %TEMP%\\map[.]txt.
3[.]vbs downloads the appropriate payload guided by the state values and writes it to %TEMP%\\out[.]enc. 4[.]vbs decrypts out[.]enc via runner.ps1, writes sys_cache.zip, and executes PyTorchFix.ps1. Payloads vary: 000/001 yield a backdoor; 010 enables UAC-bypass and persistence tooling; 011 deploys tunnelling utilities and a cryptocurrency miner.
The operation is worm-like: each infected ScreenConnect session can infect new hosts through subsequent connections, with the attacker discarding session IDs after a disconnect to re‑trigger on reconnection.
ConnectWise has issued an advisory about a file-transfer behavior issue affecting Cloud and On‑Prem deployments. Huntress recommends re-imaging affected hosts from known-good media, and temporary mitigations include disabling file transfer permissions in ScreenConnect roles.