An infected ScreenConnect guest pushes scripts up the support session to the operator's host

The trigger is the operator's own click. A modified client sitting on an infected Guest monitors for new Host connections ^[5], and when one arrives it uses ScreenConnect's virtual file-transfer and Run functionality to send scripts to that Host and request execution ^[6]. Huntress notes that after the initial compromise, propagation through a remote-support session may occur without a separate user action to launch the transferred scripts ^[25]. A later reconnection can start the sequence again, so the same mechanism both spreads infection and can reinfect ^[7].

That inverts the direction the tool's terminology assumes: the Guest is the endpoint receiving support, the Host is the operator side ^[3]. A support tool whose job is moving files and running them will move files and run them.

Which is what makes the audit signal useful. Huntress points to ScreenConnect audit entries involving RunFiles or RanFiles from Process: Guest, correlated with execution on the connected Host ^[15]. The anomaly is the direction, since that flow normally runs the other way. On the endpoint, the listed indicators are ScreenConnect spawning wscript.exe, execution of 1.vbs through 4.vbs, and a WindowsServiceHost entry under the current user's Run key ^[14]. That is four scripts ^[22], and their job is to assess the environment, retrieve configuration and payload files, and use PowerShell to decrypt and run the selected payload ^[10].

The interim control is a setting. Huntress's September 3 update relayed ConnectWise's advice to disable TransferFiles, or TransferFilesInSession in legacy versions ^[16]. Turning that off removes the transport this campaign uses, and it also removes in-session file transfer for every legitimate technician on the instance. The report also points to BleepingComputer coverage headlined "ConnectWise warns of new ScreenConnect flaw without patch" ^[20], so the toggle is what is available rather than what anyone would prefer.

Worth bounding the worm language. Huntress describes propagation through ScreenConnect sessions, not unrestricted scanning and infection of arbitrary devices on the network ^[8]. The material describes travel from infected Guest to connecting Host ^[2][6]; it does not describe a compromised Host going on to transfer scripts to the other Guests it supports ^[26]. The blast radius the evidence supports is the session graph, and the helpdesk endpoint is the node with the most edges.

Do not assume you know what ran. Execution branches by endpoint conditions into user-level remote access, persistence and privilege escalation, or tunneling and cryptocurrency mining ^[11], which are three separate branches ^[23]. Huntress is explicit that UAC bypass, persistence, tunneling and mining should not be treated as stages occurring on every infected endpoint ^[12], and that UAC bypass alone does not establish a process running as SYSTEM ^[13]. Branch-dependent artefacts include ComputerDefaults.exe, PyTorchFix.ps1, Themes.exe and SearchIndex.exe ^[18].

That branching is why the remediation line is what it is: Huntress recommends reimaging affected endpoints from known-good media or a clean operating-system install, because removing only the visible tunnel or modified client may leave other components behind ^[17]. If you keep in-session transfer enabled, your detection is the Guest-initiated RunFiles correlation ^[15], and your recovery budget is a rebuild per touched machine ^[17].