A sophisticated malware campaign is weaponizing ConnectWise ScreenConnect software to deploy a multi-stage VBScript chain and worm-like capabilities across Windows systems, according to research published by Huntress. Detected in late August across unrelated organizations, the attacks leverage modified remote-access clients that automatically push payloads to newly connected endpoints.
Attack Delivery and Initial Access Vectors
The malicious campaign relies heavily on social engineering to trick users into installing attacker-controlled ConnectWise ScreenConnect clients, according to findings from Huntress. Investigators identified several initial-access scenarios behind the deployments. These include fake Quick Assist support interactions, phishing emails distributing rogue ScreenConnect.ClientSetup.msi installers, and a fraudulent Geek Squad refund search that steered victims into launching a malicious ScreenConnect.Client.exe.
In one analyzed incident, a rogue client connected directly to the IP address 45.13.237[.]190. Other active command-and-control infrastructure observed by researchers included 131.123.40[.]98:8041, 15.204.185[.]204, and the domain borertors92.anondns[.]net. On several compromised endpoints, investigators found additional remote monitoring and management tools—such as UltraViewer—installed alongside the malware, a tactic operators use to retain access and complicate incident response.
Multi-Stage VBScript Execution Chain
Once a victim runs the modified software, the rogue ScreenConnect client monitors host-session collections, identifies newly connected systems, and transfers a four-stage script chain through its virtual file-transfer mechanism. The malware copies scripts 1.vbs through 4.vbs into C:UsersPublicLibrariesDefaultLibLib1 on the target machine, repeatedly spawning wscript.exe from temporary directories.
- 1.vbs (Host Profiling): This script creates a three-bit state value stored in
%TEMP%value.txt. It checks for existing ScreenConnect installations, evaluates available RAM to avoid low-resource analysis virtual machines, and scans for enterprise security products. Specifically, the script checks for services associated with Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos, and Malwarebytes. If it detects a pre-existing ScreenConnect client, execution aborts. - 2.vbs (Configuration Retrieval): This script downloads a Dropbox-hosted, Base64-encoded and XOR-obfuscated configuration file, saving the decoded result as
%TEMP%map.txt. This configuration maps the host state values to encrypted payload URLs and AES keys. - 3.vbs (Payload Extraction): Operating according to the downloaded map, this script retrieves the appropriate encrypted archive and stores it locally as
out.enc. Huntress observedScreenConnect.WindowsClient.exedirectly spawningwscript.exeduring this phase. - 4.vbs (PowerShell Deployment): This final script writes and launches
%TEMP%runner.ps1utilizing an execution-policy bypass. The PowerShell loader decryptsout.encusing AES-CBC, extracts a ZIP archive to the user profile, executesPyTorchFix.ps1, terminates script-host processes, and removes staging artifacts.
Identified Payload Outcomes and Persistence
Depending on the environment profile gathered during the initial infection phase, Huntress analysts documented three distinct payload outcomes: a user-level ScreenConnect backdoor, an access package equipped with persistence and privilege-escalation tooling, or a combined package containing network tunneling and cryptocurrency-mining components.
To maintain persistence across reboots, the malware frequently establishes a WindowsServiceHost user Run key pointing to WindowsServiceHost.vbs located inside the victim’s AppData directory. Investigators also recovered a related WindowsServiceHost.bat file in at least one analyzed breach.
Worth a look