Huntress investigation: three unrelated access routes
Huntress disclosed three separate incidents that converged on the same post-compromise mechanics. The initial access vectors differed: a tech-support scam that convinced a user to run Quick Assist; an MSI installer named ScreenConnect.ClientSetup.msi believed to have been distributed by phishing; and a lure based on a fake "Geek Squad refund form." In each instance a rogue ScreenConnect client was installed and configured to contact external command-and-control infrastructure. Observed C2 endpoints included 45.13.237[.]190 (tele-sync.opik[.]net), 131.123.40[.]98 on port 8041, and borertors92.anondns[.]net. The activity was observed in August 2026.
Four-stage VBScript chain: how the infection advances
Once the rogue ScreenConnect client was active, Huntress said the client repeatedly spawned wscript.exe to run four VBScripts named 1.vbs, 2.vbs, 3.vbs and 4.vbs. The scripts operate as a chained staging mechanism: 1.vbs profiles the host and writes a three-bit state value to %TEMP%\\value.txt; 2.vbs waits for that file, checks for the word "abort," and if absent downloads and decodes content to %TEMP%\\map.txt (the Dropbox URL is offline as of September 2, 2026); 3.vbs then waits for map.txt and pulls the file referenced there to %TEMP%\\out.enc based on the state bits; and 4.vbs waits for out.enc, launches %TEMP%\\runner.ps1 to decrypt out.enc, writes the result to %APPDATA%\\Microsoft\\Windows\\Templates\\Classic\\sys_cache.zip, and executes a second-stage PowerShell script named PyTorchFix.ps1.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleState-driven payloads and destructive cleanup
Huntress mapped at least three payload branches tied to the three-bit state value set by 1.vbs. Values 000 and 001 delivered a user-level ScreenConnect backdoor; 010 delivered tooling for privilege escalation via a UAC bypass and persistence; and 011 delivered tunneling utilities plus an XMRig cryptocurrency miner. The 011 branch also contained steps to disable Microsoft Defender reporting and turn off Windows memory integrity. The runner.ps1 script is scripted to terminate every wscript.exe or cscript.exe process and to delete the staging directory after execution. For state values 010 or 011, 4.vbs also writes the four VBScript files to C:\\Users\\Public\\Libraries\\Default\\Lib\\Lib1, a placement Huntress linked to continued propagation.
Propagation mechanics: ScreenConnect clients becoming delivery points
Huntress observed that compromised ScreenConnect clients not only executed the chain locally but also served as content-delivery mechanisms for further infections. After the four scripts are placed into the Public Libraries path, the infected client will trigger deliveries when it detects a new Host connection. Huntress noted the malware records each ConnectionID to avoid re-targeting the same active session but “then removes that identifier after it disconnects – allowing a later reconnection to trigger the infection again.” That behavior is the basis for the firm's description of worm-like spreading across ScreenConnect sessions.
Indicators, tool overlap, and remediation advice
Additional indicators Huntress reported include a WindowsServiceHost User Run Key pointing to WindowsServiceHost.vbs in the user’s AppData directory. The company also observed other remote monitoring and management (RMM) tools, including UltraViewer, present on some impacted hosts. Given the breadth and complexity of the chains and the presence of privilege-escalation and persistence components, Huntress recommended re-imaging affected hosts from known-good media or performing a clean operating system install.
ConnectWise advisory and immediate mitigations
ConnectWise issued an advisory saying it identified an issue affecting file transfer behavior in ScreenConnect Remote Access Support and Access sessions, impacting both Cloud and On-Premise deployments. As a temporary mitigation until a fix is available, ConnectWise recommended disabling technician file-transfer permissions in each ScreenConnect role. The company’s steps: log into Administration, go to Administration > Security > Roles, edit assigned roles, check each session group’s Scoped Permissions, deselect TransferFiles (or TransferFIlesInSession for legacy versions), save the role, and repeat for all roles defined in the instance or installation.
The incidents combine social engineering, staged scripting, state-based payload selection, and reuse of remote-access infrastructure to turn a remote-management channel into a propagation vector. Huntress’s recommendation to re-image affected hosts and ConnectWise’s advice to remove file-transfer permissions speak to two immediate defensive paths: eliminate persistent compromises and reduce the capability for a technician session to drop and execute staged scripts. For defenders, the central remaining question is whether further instances will appear tied to other RMM tools or to new initial-access lures; for operators of ScreenConnect instances, the urgent steps are to audit role permissions, inventory recent client installs, and follow Huntress’s re-imaging guidance where compromise is confirmed.
Source: https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
