Huntress has documented three unrelated incidents from August 2026 involving rogue ScreenConnect clients that carry a four-stage VBScript chain and spread it to machines as they connect.
The clients arrive three ways: a Quick Assist tech-support scam that talks the user into running the tool, a phishing email carrying ScreenConnect.ClientSetup.msi, and a fake Geek Squad refund form.
There is no vulnerability to patch
This is the first thing to be clear about, because it changes what you do this morning.
The propagation abuses file transfer behaviour in ScreenConnect sessions — legitimate functionality, working as designed. It is not a code execution flaw, there is no CVE to look up, and no patch exists yet.
ConnectWise's advisory is a permission change: disable TransferFiles under Administration, Security, Roles, for all session groups, until a patch is available.
If you run ScreenConnect, that is the action. It does not wait for a maintenance window.
The worm behaviour
A compromised client writes its VBS files to C:\Users\Public\Libraries\Default\Lib\Lib1. When that client sees a new host connect, the four-stage chain executes on the connecting system.
The operators track ConnectionIDs so they do not re-target the same host — and delete the record after disconnect, which means a machine that reconnects gets infected again.
The trust relationship being abused is the one the product exists to create. A support tool's whole purpose is that many machines connect to it and accept what it sends. This is the third remote-management product in two days to end up in the same place, and the pattern is not coincidence: the software that legitimately reaches everything is the most useful thing on the network to compromise.
The three-bit state machine
The chain is worth walking through, because the design is the interesting part.
1.vbs profiles the host. It checks system resources — whether RAM is over 5 GB — and enumerates installed security products: Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, Symantec. It writes a three-bit state variable to %TEMP%\value.txt.
2.vbs waits for that file, and if no abort flag is set, downloads a payload from Dropbox, decoding it to %TEMP%\map.txt.
3.vbs waits for map.txt and downloads a state-specific file to %TEMP%\out.enc.
4.vbs runs PowerShell to decrypt it into sys_cache.zip under the user's AppData Templates directory, and executes PyTorchFix.ps1.
What arrives depends on the bits:
| State | Payload |
|---|---|
| 000 / 001 | user-level ScreenConnect backdoor |
| 010 | UAC bypass tooling and persistence |
| 011 | tunnelling utilities and the XMRig miner |
Read that table backwards and you have the operator's business logic. A host with EDR and modest resources gets a quiet backdoor or nothing. A host where privilege escalation looks viable gets escalation tooling. A fat, unmonitored machine gets turned into a miner.
That is triage. The malware is doing inventory grading before deciding what the machine is worth, which is the same economic logic we described in the BraZetsu piece — except here the grading happens on the endpoint, before the operator has to spend anything.
The filename PyTorchFix.ps1 is a small, deliberate touch: it is meant to look like something a developer or an IT team would run.
Indicators
- 45.13.237[.]190, resolving tele-sync.opik[.]net
- 131.123.40[.]98 on port 8041
- borertors92.anondns[.]net
- Persistence: WindowsServiceHost.vbs in the user's AppData directory
- Staging path: C:\Users\Public\Libraries\Default\Lib\Lib1
- %TEMP%\value.txt, map.txt, out.enc
The Dropbox URLs stopped resolving on 2 September, so those are for retrospective hunting rather than blocking.
What to do
- Disable TransferFiles for all session groups now. There is no patch, and this is the mitigation ConnectWise named.
- Inventory your ScreenConnect instances, including ones you did not deploy. Two of the three delivery routes install a client the victim believes is legitimate support software.
- Hunt the staging path and the temp files. value.txt, map.txt and out.enc in %TEMP% alongside a Public\Libraries path is not ambiguous.
- Search for WindowsServiceHost.vbs across user AppData.
- Treat reconnection as re-exposure. The operators delete their ConnectionID record on disconnect, so a cleaned machine that reconnects to an unclean server is back where it started. Clean the server first.
- Tell your help desk about the Quick Assist and Geek Squad lures. The initial access is a conversation, not an exploit.
What is not established
- What the 2.vbs Dropbox payload actually was. The URLs are offline.
- How widely this spread. Three incidents have been described; no victim count or sector breakdown has been published.
- Whether a patch is coming, or when.
- Who is running it. No attribution has been offered.
