One Support Session Could Infect the Next PC
The ScreenConnect guest file transfer feature can turn an ordinary remote-support connection into a bridge between an infected computer and the next machine a technician touches.
Huntress found modified ScreenConnect clients that watch for a new support connection, then automatically transfer and execute four VBScript files on the connected endpoint. ConnectWise has acknowledged an issue in the file-transfer behaviour of ScreenConnect Remote Access Support and Access sessions. It affects both cloud and on-premises deployments.
There is no patch yet. ConnectWise says a fix and a CVE identifier are in development. Until then, the vendor is telling customers to disable technician file transfer for every role and every session group.
This is not an unauthenticated internet worm. Every incident Huntress described began with social engineering, Quick Assist abuse or phishing. The dangerous part comes afterwards: once the modified client is present, a legitimate support session can supply the next connection the malware needs to spread.
Four scripts crossed the support connection
Huntress initially saw the same unusual behaviour across unrelated organisations. Rogue ScreenConnect clients repeatedly spawned wscript.exe to run files named 1.vbs, 2.vbs, 3.vbs and 4.vbs. Investigators also found a user-level Run key named WindowsServiceHost pointing to WindowsServiceHost.vbs inside the user’s AppData directory.
The four-stage payload profiled the endpoint, checked its memory and security tooling, looked for existing ScreenConnect installations and pulled additional content from Dropbox. Variants created a user-level ScreenConnect backdoor, attempted persistence and privilege escalation, established tunnels and deployed a cryptocurrency miner.
The scripts also attempted to bypass User Account Control through the ms-settings and ComputerDefaults path, interfere with the Antimalware Scan Interface and add a Microsoft Defender exclusion. None of those steps makes the campaign invincible. They do show that the propagation mechanism is attached to a broader attempt to retain access and reduce visibility.
The modified client waits for the next connection
The most consequential behaviour sits inside the altered ScreenConnect client. Huntress says it monitors EndPointStatusMessage.Connections. When another ScreenConnect endpoint connects, the client uses the session to transfer and execute the same four scripts on that machine.
That creates worm-like movement without the broad scanning normally associated with a network worm. The attacker does not have to discover an exposed service on the next endpoint. The remote-support workflow supplies a trusted relationship, a connection and a file-execution path.
For managed service providers, that boundary matters more than the malware family attached to it. A support tool is deliberately allowed to cross organisational and device boundaries. If the connected client can silently push code back through that channel, one compromised endpoint can turn routine support activity into a delivery mechanism.
The first victim still has to be tricked
Huntress did not describe attackers exploiting an internet-facing ScreenConnect server without credentials. In one incident, a victim was persuaded to use Windows Quick Assist. In another, a search for a Geek Squad refund form led the victim to download a rogue ScreenConnect client. Some affected systems also contained UltraViewer, another legitimate remote-access tool commonly abused in support scams.
That prerequisite should shape the response, but it should not reduce the urgency. Social engineering provides the initial foothold. The product behaviour can then amplify the compromise by carrying executable files into a later support session.
Descriptions such as worm-like activity are therefore accurate only with context. The propagation is automatic after the malicious client is installed, but the first infection is not automatic and the campaign is not indiscriminately spreading across the public internet.
ScreenConnect guest file transfer is the immediate control point
ConnectWise says the interim mitigation applies to both ScreenConnect cloud and on-premises environments. Administrators should open the Administration page, go to Security > Roles and inspect every session group assigned to every role.
If TransferFiles is enabled, disable it. Legacy versions may call the permission TransferFilesInSession. The check must cover each role and each scoped session group, not only the default technician role. ConnectWise says the change takes effect without a version upgrade.
The mitigation has an operational cost because technicians may legitimately need to move tools, logs and installers. That is still preferable to leaving an acknowledged execution path available while no patched build exists. Organisations that cannot disable transfer everywhere should reduce it to the smallest set of tightly controlled roles and sessions, then monitor those exceptions closely.
Hunt for scripts launched by the guest process
Huntress recommends reviewing ScreenConnect audit logs for RunFiles or RanFiles events involving the numbered scripts. Entries showing those files executed from Process: Guest should be treated as suspicious.
- Search endpoints for
1.vbsthrough4.vbs, especially when launched bywscript.exebeneath a ScreenConnect client. - Inspect user Run keys for
WindowsServiceHostand references toWindowsServiceHost.vbsinAppData. - Look for unexpected ScreenConnect or UltraViewer installations, hidden services and new remote-access configurations.
- Review Defender exclusions, suspicious
ms-settingsactivity, tunnel processes and cryptocurrency-mining indicators. - Block or investigate connections to
45.13.237.190,131.123.40.98,15.204.185.204,tele-sync.opik.netandborertors92.anondns.net. - Identify support sessions that connected to a suspect endpoint after the first compromise. Those destination machines deserve priority review even if they have not raised an alert.
Indicators can change, and an attacker can rename scripts. The behavioural sequence is more durable: a rogue client, repeated Windows Script Host launches, file execution from the guest process and a new remote-access or persistence mechanism.
A patch is promised, but the affected range is still unknown
ConnectWise has not published a CVE identifier, severity score, affected-version range or fixed version. Its advisory says a CVE and patched release will follow after cloud rollout. The company expected to provide them within a week of the 3 September advisory.
Those missing details prevent defenders from treating an installed version as proof of safety. Until the bulletin changes, the mitigation is permission-based rather than version-based. Cloud customers should not assume that provider-managed hosting removes the exposure because ConnectWise explicitly lists cloud and on-premises deployments as affected.
The eventual patch will close the product behaviour. It will not clean endpoints that already received the scripts. Any organisation that finds the described activity should isolate affected systems, preserve ScreenConnect and endpoint telemetry, identify connected machines and carry out an incident investigation rather than relying on the update alone.
Remote support is a trust path, not just a tool
Remote-support products are powerful because they can cross the same boundaries attackers want to cross. They connect technicians to users, MSPs to customers and privileged operators to endpoints that may sit in otherwise separated environments.
The ScreenConnect activity shows why those connections must be governed like privileged network paths. File transfer, script execution and unattended access are not harmless convenience features. Each one is a capability that should be limited by role, logged centrally and reviewed when the source endpoint becomes suspect.
The first victim in this campaign had to be fooled. The next computer only had to trust the support session.
ScreenConnect incident questions
Is this a ScreenConnect zero-day?
ConnectWise has acknowledged a guest file-transfer issue and says a CVE and official fix are coming. It has not yet published an affected-version range, severity score or fixed build. Calling it an acknowledged unpatched flaw is more precise than assigning a label the vendor has not yet used.
Can ScreenConnect malware spread without user interaction?
The initial infection in every Huntress case involved social engineering, Quick Assist or phishing. After a modified client is installed, its transfer of the four scripts to a newly connected endpoint can occur automatically through the support session.
What should ScreenConnect administrators do before a patch exists?
Disable TransferFiles, or TransferFilesInSession on legacy versions, for every role and scoped session group. Then inspect audit and endpoint logs for the published script, process, persistence and network indicators.
Sources and further reading
- Huntress: rogue ScreenConnect installations across unrelated hosts suggest worm-like activity, published 3 September 2026 at 08:50 UTC, 10:50 Europe/Madrid. Updated 3 September 2026 at 17:45 ET, 23:45 Europe/Madrid.
- ConnectWise: ScreenConnect Remote Access guest file transfer advisory, published 3 September 2026. No publication time was provided.
- BleepingComputer: ConnectWise warns of new ScreenConnect flaw without a patch, published 7 September 2026 at 06:06 as displayed. The page does not label its timezone.
