On September 3, 2026, ConnectWise issued an emergency advisory telling ScreenConnect administrators to disable file transfers immediately. Huntress had discovered attackers weaponizing ScreenConnect’s file transfer capability to spread malware across managed environments — turning a legitimate remote access tool into a worm delivery mechanism.
The attack worked because ScreenConnect, like most remote management tools, has permission to write files to disk. That’s a feature, not a bug. Technicians need to transfer logs, patches, and configuration files. But attackers exploited the same capability to land malicious payloads.
What Happened
Every incident began with social engineering. The victim was tricked into installing a rogue ScreenConnect client controlled by the attacker. Once that client connected to the victim’s machine, it immediately began writing four VBScript files to the user’s AppData directory: 1.vbs, 2.vbs, 3.vbs, and 4.vbs.
The scripts performed system reconnaissance, established persistence through a Windows registry Run Key named WindowsServiceHost, and retrieved additional payloads: more ScreenConnect clients, tunneling tools, cryptocurrency miners, and scripts to disable security controls.
The most dangerous part: the compromised ScreenConnect client propagated the same VBScript chain to every newly connected endpoint. If a technician used ScreenConnect to manage ten client machines, all ten got infected. Worm-like spread across an entire managed environment.
ConnectWise’s recommended mitigation was to disable file transfers for all technicians until a patch could be issued. That stops the attack, but it also breaks legitimate workflows. Technicians can’t transfer files at all — not malicious scripts, and not the logs and patches they actually need to do their jobs.
Why It Worked
Remote access tools need elevated privileges to function. ScreenConnect runs with enough permission to write files anywhere a technician might need to place them. Windows file permissions don’t distinguish between a technician transferring a legitimate patch and an attacker transferring a malicious script — both operations look identical to the operating system.
Signature-based antivirus might catch known malware, but these were custom VBScript files designed to evade detection. By the time the scripts were flagged as malicious, they’d already executed and established persistence.
How FileSure Would Have Prevented It
FileSure Defend operates at the Windows kernel level, intercepting file operations before they complete. A single rule blocks remote access tools from writing executable file types to disk:
File name filter: *.vbs;*.exe;*.dll;*.ps1;*.bat;*.cmd
Program name filter: screenconnect.clientservice.exe (or a wildcard pattern matching common RMM tools)
Operations: Write, Create
Drive type: All local drives
Result: Deny
When the compromised ScreenConnect client attempts to write 1.vbs to the AppData directory, FileSure intercepts the write operation and blocks it. The file never lands on disk. No payload means no execution, no persistence mechanism, no worm behavior, and no secondary infections.
ScreenConnect can still transfer non-executable files — Word documents, Excel spreadsheets, log files, images, anything a technician legitimately needs. The rule is specific: it blocks executable file types from being written by remote access tools, not all file transfers from all programs.
The social engineering that gets the rogue ScreenConnect client installed in the first place? Still a problem. But the malware that client tries to deliver never touches the file system. The attack is stopped at the payload landing stage, before any damage occurs.
FileSure logs every blocked attempt with full context: which user, which program, which file, exact timestamp. When you investigate, you see exactly what the attacker tried to do — and proof that it was stopped.
Upstream Prevention Beats Downstream Detection
Most security tools try to detect malicious behavior after the payload executes. FileSure prevents the payload from landing in the first place. No encryption, no data exfiltration, no lateral movement — because the malware never gets written to disk.
That’s the difference between blocking a file write operation and trying to recognize a malicious script after it’s already running.
Start a free trial of FileSure Defend at bystorm.com and see how kernel-level file operation control stops attacks that application-layer tools miss.
Source: Attackers spread malware through ScreenConnect file transfers – Help Net Security
Category: Ransomware
Tags: screenconnect, rmm abuse, vbscript malware, remote access exploit, kernel filter driver, file system security, lateral movement, connectwise
