Cybersecurity researchers have uncovered worm-like malware activity that exploits ConnectWise ScreenConnect to deliver a malicious Visual Basic Script payload to newly connected systems. According to Huntress, three separate incidents were detected in August 2026 that used different 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 leading to rogue ScreenConnect installations. Once the ScreenConnect instances were installed, the clients repeatedly spawned "wscript.exe" to execute VBScripts named 1.vbs, 2.vbs, 3.vbs, and 4.vbs.

The attack sequence follows a four-step process, with each VBScript launching the next. The first script profiles the host, checks system resources like whether RAM exceeds 5 GB, verifies if ScreenConnect is installed, enumerates security products including Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, and Symantec Endpoint Protection, and writes the results to "%TEMP%\value.txt" as a three-bit state variable. For instance, the state value "000" signals no existing ScreenConnect installation, the presence of third-party security processes, and no ScreenConnect clients in the Program Files folder. The second script waits for the "%TEMP%\value.txt" file and checks for the word "abort"—if absent, it downloads a file from Dropbox, decodes its contents, and writes them to "%TEMP%\map.txt." The third script waits for "%TEMP%\map.txt" and then downloads the relevant file from the Dropbox link specified in the text file based on the state values set by the first script, writing it to "%TEMP%\out.enc." The fourth script waits for the downloaded "%TEMP%\out.enc" payload and launches a PowerShell script to decrypt its contents, write them to "%APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip," and execute a second-stage PowerShell script called "PyTorchFix.ps1." At least three different payloads have been detected: state values 000 and 001 lead to a user-level ScreenConnect backdoor, 010 leads to tooling for privilege escalation via a User Account Control bypass and persistence, and 011 leads to tunneling utilities and a cryptocurrency miner.

Huntress said the 4.vbs script also writes the four VBScript files to "C:\Users\Public\Libraries\Default\Lib\Lib1" if the value in "%TEMP%\value.txt" is set to 010 or 011, which "creates a worm-like behavior: propagating infections over new ScreenConnect connections." According to the cybersecurity company, "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. The incidents share additional indicators, including a WindowsServiceHost User Run Key pointing to WindowsServiceHost.vbs in the user's AppData directory, and Huntress observed other remote monitoring and management tools, including UltraViewer, on some impacted hosts.

The worm-like behavior turns compromised hosts into content-delivery mechanisms for the malicious scripts every time the backdoored client observes a new Host connection, allowing the infection to spread automatically across ScreenConnect networks. The state value branch "011"—which translates to no existing installation of ScreenConnect on the system, Microsoft Defender as the only endpoint protection program installed, and no ScreenConnect clients present—includes payloads to disable Microsoft Defender reporting, turn off Windows memory integrity, and runs an XMRig cryptocurrency miner. Considering the extent and complexity of these attack chains, Huntress made strong recommendations that affected hosts be re-imaged from known-good media or a clean operating system install.

In response to the findings, ConnectWise has issued an advisory stating it has identified an issue affecting file transfer behavior in ScreenConnect Remote Access Support and Access sessions that 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 through the Administration page by navigating to Administration > Security > Roles, editing roles assigned to users, and deselecting the TransferFiles permission for each session group. The advisory provides a clear path for administrators to shut down the attack vector while ConnectWise develops a permanent solution. Remote management tools remain an attractive target for sophisticated attackers, and organizations relying on third-party access software may need to reassess their trust boundaries and monitoring protocols regardless of vendor reputation.