Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts
A sophisticated worm-like attack is leveraging ConnectWise ScreenConnect to spread a four-stage VBScript chain, targeting newly connected hosts. The attack utilizes social engineering, phishing, and fake refund forms to deploy rogue ScreenConnect clients, which then propagate malicious scripts across networks. The campaign involves a complex sequence of VBScripts designed to disable security measures, escalate privileges, and potentially mine cryptocurrency. ConnectWise has issued an advisory and recommended disabling file transfer capabilities within ScreenConnect to mitigate the risk.
Cybersecurity researchers have disclosed details of worm-like activity exploiting ConnectWise ScreenConnect to distribute a malicious Visual Basic Script (VBScript) payload to newly connected systems. According to Huntress, three unrelated incidents have been found to use diverse initial access methods – a Quick Assist tech-support scam, a phishing-delivered MSI installer, and a fake Geek Squad refund form lure – to activate a four-stage VBScript chain that leads to rogue ScreenConnect remote access clients.
Once the ScreenConnect clients were installed, the cybersecurity company observed the clients repeatedly spawning "wscript.exe" to execute VBScripts named 1.vbs, 2.vbs, 3.vbs, and 4.vbs. The incidents were observed in August 2026. The campaign involved a complex sequence of VBScripts designed to disable security measures, escalate privileges, and potentially mine cryptocurrency.
Across these incidents, the attack sequence followed a four-step process, with each VBScript launching the next and allowing it to progress further. The state value branch "011" – (1) no existing installation of ScreenConnect on the system, (2) Microsoft Defender is the only endpoint protection program installed on the machine, and (3) no ScreenConnect clients are present – included payloads to disable Microsoft Defender reporting, turn off Windows memory integrity, and run an XMRig cryptocurrency miner. The state value branch "010" led to tooling for privilege escalation via a User Account Control (UAC) bypass and persistence. The state value branch "000 and 001" led to a user-level ScreenConnect backdoor.
Each VBScript file – 1.vbs, 2.vbs, 3.vbs, and 4.vbs – played a specific role in the chain. 1.vbs profiled the host, checked system resources (e.g., if RAM is over 5 GB), verified if ScreenConnect was installed, enumerated security products (including Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, and Symantec Endpoint Protection), and wrote the results of these checks to "%TEMP% ile.txt" in the form a three-bit state variable. 2.vbs waited for the "%TEMP% ile.txt" file and checked for the presence of the word "abort." If the word did not exist, it downloaded a file from Dropbox, decoded its contents, and wrote them to "%TEMP% ile.txt." 3.vbs worked similarly to 2.vbs by waiting for "%TEMP% ile.txt" and then proceeded to download the relevant file from the Dropbox link specified in the text file based on the state values set by 1.vbs and wrote it to "%TEMP% ile.enc." 4.vbs waited for the presence of the downloaded "%TEMP% ile.enc" payload and launched a PowerShell script ("%TEMP% unner.ps1") to decrypt the contents of "%TEMP% ile.enc," write them to "%APPDATA% emp ile.zip," and execute a second-stage PowerShell script ("PyTorchFix.ps1").
In addition, "%TEMP% unner.ps1" took steps to terminate every "wscript.exe" or "cscript.exe" process, and deleted the staging directory after the final stage was run. The 4.vbs script also wrote the four VBScript files to "C:\Users\Public\Libraries\Default\Lib\Lib1" if the value in "%TEMP% ile.txt" was set to 010 or 011. This, in turn, triggered a round of payload deliveries, effectively turning the compromised host into a content-delivery mechanism for the malicious scripts every time the backdoored client observed a new Host connection. The campaign creates a worm-like behavior: propagating infections over new ScreenConnect connections. Connecting to an infected ScreenConnect client can cause the server-side Host system to receive and execute the same four-stage VBScript chain. Later, the client records each ConnectionID to avoid repeatedly targeting the same active session, but then removes that identifier after it disconnects – allowing a later reconnection to trigger the infection again.
Huntress observed other remote monitoring and management (RMM) tools, including UltraViewer, on some impacted hosts. ConnectWise has issued an advisory, stating it has identified an issue affecting file transfer behavior in ScreenConnect Remote Access Support and Access sessions. The issue, it added, impacts both Cloud and On-Premise deployments. Until a fix is in place, customers are recommended to mitigate the risk by disabling the ability for technicians to transfer files – logging into the Administration page of ScreenConnect instance or installation, navigating to the Administration > Security > Roles section, editing a role that is assigned to users, reviewing each session group that has permissions assigned to it, and deselecting the TransferFiles permission (or TransferFIlesInSession for legacy versions) if it is selected.