Contain ScreenConnect file-transfer risk

The September 7, 2026 assessments report demonstrated rogue-client delivery and execution of 1.vbs–4.vbs and WindowsServiceHost.vbs persistence through ScreenConnect sessions.

That evidence supports immediate reduction of file-transfer exposure and indicator-based hunting without waiting for version-specific patch information.

The absence of a primary vendor advisory and fixed-build evidence limits patch guidance, but it does not prevent disabling file transfer, preserving telemetry, or isolating systems when concrete transfer, execution, persistence, or unauthorized-administrator evidence appears.

The guidance applies to ScreenConnect Cloud and ScreenConnect On-Premise deployments running Remote Access Support and Access sessions with direct exposure or TransferFiles or legacy TransferFilesInSession enabled.

ScreenConnect servers face the need for containment and investigation when rogue-client transfer or unauthorized-administrator evidence appears.

Windows endpoints reached through those sessions face script execution through ScreenConnect.WindowsClient.exe and wscript.exe, plus WindowsServiceHost.vbs persistence.

ScreenConnect administrators, support operators, and security teams must distinguish malicious activity from legitimate benign-file transfers and generic child processes.

No specific On-Premise version range is established, and the packet contains no deployment-specific evidence identifying individual exposed installations.

Support — Alex Mercer’s September 7, 2026 threat-hunter assessment reports a ScreenConnect file-transfer issue involving Cloud and On-Premise Remote Access Support and Access sessions, and reports rogue clients transferring and executing 1.vbs–4.vbs with WindowsServiceHost.vbs persistence. It also contradicts broader claims by noting that no published CVE, affected-version boundary, exploit primitive, actor, or fixed on-premises build was established.

Support — James Okafor’s September 7, 2026 defense-architect assessment identifies concrete isolation triggers: execution of 1.vbs–4.vbs, ScreenConnect.WindowsClient.exe spawning wscript.exe, WindowsServiceHost.vbs persistence, an unauthorized administrator, or an unapproved script or executable transferred by a rogue client. It states that generic child processes, benign transfers, and missing logs do not by themselves prove compromise.

Support — The evidence audit found both assessments aligned on disabling file transfer, preserving telemetry, hunting relevant sessions and endpoints, and isolating systems when transfer, execution, persistence, or unauthorized-administrator evidence appears.

Evidence gap — The audit found no primary vendor advisory validating the reported vendor attribution, exact scope, affected versions, or fixed build.

The threat hunter first challenged an overbroad account of the exploit mechanics, while identifying reported ScreenConnect file transfer and the demonstrated delivery and execution of 1.vbs–4.vbs with WindowsServiceHost.vbs persistence.

The defense architect converted those observations into isolation thresholds and distinguished suspicious indicators from legitimate support activity and missing logs.

The evidence audit supported the shared containment actions but identified two gaps: no primary vendor advisory and no affected-version boundary or validated fixed on-premises build. The boundary review found the limited, conditional guidance publicly supportable.

With no prior record retrieved, the arbiter selected a new operational decision focused on containment rather than unsupported patch or attribution claims.