ScreenConnect worm spreads via guest file transfer

Huntress published a research writeup on rogue ScreenConnect clients with worm-like spread, updated 3 September 2026 at 5:45 ET after a ConnectWise advisory. It is MDR research plus a product trust notice. It is not a numbered CVE yet, and it is not a cloud-outage bulletin.

In late August the Huntress SOC saw critical incidents across unrelated organizations. Rogue ScreenConnect clients spawned wscript.exe to run 1.vbs, 2.vbs, 3.vbs, and 4.vbs. Persistence was a User Run Key named WindowsServiceHost pointing at WindowsServiceHost.vbs under AppData. Some hosts also received UltraViewer.

Initial access was social engineering: a Quick Assist tech-support scam, a phishing MSI named ScreenConnect.ClientSetup.msi, and a Geek Squad refund lure that dropped ScreenConnect.Client.exe. C2 examples include 45.13.237.190 (tele-sync.opik.net), 131.123.40.98 on port 8041, and borertors92.anondns.net.

The worm step is the guest file transfer. Modified clients watch EndPointStatusMessage.Connections for new Host sessions, then push the four VBS files through ScreenConnect virtual file transfer with action Run. ConnectionIDs are tracked during a session and cleared on disconnect, so a later reconnect can infect again. One backdoored client ID Huntress recovered is 7a4d7d66502d4260.

The four-stage chain profiles the host, then stages payloads. 1.vbs builds a 3-bit state (existing ScreenConnect, EDR presence, RAM over 5GB). 2.vbs and 3.vbs pull a Dropbox map and AES-encrypted packages. 4.vbs decrypts and can install backdoored clients, attempt a ComputerDefaults/ms-settings UAC bypass, try an AMSI bypass, add Defender exclusions, run wstunnel as Themes.exe, run XMRig as SearchIndex.exe, and drop WinRing0 as svcdrv64.sys.

ConnectWise's 3 September advisory ("ScreenConnect Remote Access: Guest File Transfer Advisory") covers Support and Access sessions on Cloud and On-Premise. Status is fix in development, with interim mitigation available now. A CVE identifier and official fix are promised within the week after cloud rollout, and Huntress says it is in communication with ConnectWise. This is active research, not a closed postmortem.

The interim control needs no version upgrade. In Administration > Security > Roles, disable TransferFiles (or TransferFilesInSession on legacy builds) for each session group. Huntress says reimage impacted hosts, hunt audit logs for RunFiles or RanFiles of suspect scripts from Process: Guest, and treat any Guest-triggered WSH or PowerShell in a session as suspicious even if filenames change. SOC Prime summarized the same Huntress chain for detection teams.

RMM file-transfer abuse is the same class of live vendor-tool risk as the PaperCut NG/MF emergency patch, the Virtualizor malicious-update hijack, SonicWall SMA1000 zero-days, and the JFrog Artifactory auth bypass. None of those is a substitute for this week's ScreenConnect role change.

MSP, SOC, and ScreenConnect admins should disable TransferFiles and TransferFilesInSession on every role now, hunt Guest RunFiles/RanFiles and ScreenConnect.WindowsClient.exe spawning wscript.exe, inventory and remove unauthorized ScreenConnect or UltraViewer clients, and reimage any host that ran the four-stage chain.