Worm-Like ScreenConnect Abuse Spreads VBScript to New Hosts

Security researchers at Huntress have published details of worm-like abuse of ConnectWise ScreenConnect, a widely used remote access tool, in which rogue clients deliver a four-stage VBScript chain to newly connected systems. The company observed three unrelated incidents in August 2026 that began with different lures: a Quick Assist tech-support scam, a phishing-delivered MSI installer, and a fake Geek Squad refund form search. Each ultimately installed a malicious ScreenConnect client that repeatedly launched wscript.exe to run four scripts named 1.vbs, 2.vbs, 3.vbs, and 4.vbs.

The four scripts form a staged infection sequence. First, 1.vbs profiles the victim machine: it checks whether the system has more than 5 GB of RAM, verifies whether ScreenConnect is already installed, and enumerates security products including Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, and Symantec Endpoint Protection. The results are written to %TEMP%\value.txt as a three-bit state value. Huntress explains that a state of 000, for example, means no existing ScreenConnect installation, third-party security processes are present, and no ScreenConnect clients are installed under Program Files. Next, 2.vbs waits for value.txt and looks for the word abort. If the word is not present, it downloads a file from a Dropbox link, decodes the contents, and writes them to %TEMP%\map.txt. The contents of that text file are not executed, and the exact nature of the downloaded data is unclear because the Dropbox URL was already offline as of September 2, 2026. Script 3.vbs then waits for map.txt, downloads the file named in that text file based on the state value, and saves it as %TEMP%\out.enc. Finally, 4.vbs waits for out.enc, launches a PowerShell script at %TEMP%\runner.ps1 to decrypt the contents, writes the result to %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip, and then executes a second-stage PowerShell script called PyTorchFix.ps1.

The three observed incidents show how the same chain was delivered through different entry points. In the first, a user was persuaded during a tech-support scam to run Quick Assist, after which a rogue ScreenConnect remote access client contacted a command-and-control server at 45.13.237[.]190, also known as tele-sync.opik[.]net; that server hosted a RAR archive containing the four VBS files. In the second, an MSI installer named ScreenConnect.ClientSetup.msi, likely sent through phishing, deployed a client configured to reach 131.123.40[.]98 on port 8041, and the client almost immediately executed the four scripts from the ScreenConnect temporary directory. In the third, a search for a Geek Squad refund form led to a rogue executable named ScreenConnect.Client.exe that connected to borertors92.anondns[.]net and then used wscript.exe to run the same scripts from the Temp folder.

Depending on the three-bit state value, the chain selects different payloads. States 000 and 001 result in a user-level ScreenConnect backdoor. State 010 leads to tooling for privilege escalation through a User Account Control bypass and persistence mechanisms. State 011, which Huntress says means the machine has no existing ScreenConnect installation, only Microsoft Defender as its endpoint protection, and no ScreenConnect clients present, leads to tunneling utilities and an XMRig cryptocurrency miner. The state 011 payloads also disable Microsoft Defender reporting and turn off Windows memory integrity. In addition, the runner.ps1 script terminates every wscript.exe or cscript.exe process and deletes the staging directory after the final stage. If value.txt is set to 010 or 011, script 4.vbs also copies the four VBScript files to C:\Users\Public\Libraries\Default\Lib\Lib1, which helps the infection survive and spread.

Huntress describes the result as worm-like behavior. Each time an infected ScreenConnect client observes a new Host connection, it triggers another round of payload deliveries, turning the compromised machine into a content-delivery mechanism for the scripts. Connecting to an infected client can cause the server-side Host system to receive and execute the same four-stage VBScript chain. The client records each ConnectionID so it does not repeatedly target the same active session, but it removes that identifier after the session disconnects, allowing a later reconnection to trigger the infection again. Huntress also found a shared run key named WindowsServiceHost in the user profile that points to WindowsServiceHost.vbs in the AppData directory, and on some affected machines it observed other remote monitoring and management tools such as UltraViewer. Because of the complexity of these chains, the Huntress SOC strongly recommends re-imaging affected hosts from known-good media or performing a clean operating system installation.

ConnectWise has issued an advisory in response to the findings. The company says it identified an issue affecting file transfer behavior in ScreenConnect Remote Access Support and Access sessions, and the problem impacts both cloud and on-premise deployments. Until a fix is available, ConnectWise recommends that administrators disable the ability for technicians to transfer files. This involves logging into the ScreenConnect administration page, going to Administration > Security > Roles, editing each assigned role, reviewing the scoped permissions for every session group, and deselecting the TransferFiles permission (or TransferFIlesInSession on legacy versions) where it is selected, then saving the changes for each role.

For teams that manage remote access and support tools, AEU-I offers security-first IT and infrastructure consulting that can help review access roles, permissions, and remote support configurations before they become part of an attack like this.