On November 11, 2026, attackers compromised ScreenConnect panels at 48 managed service providers and deployed rogue ScreenConnect clients to at least 288 endpoints. The attack used stolen credentials or hijacked sessions to access cloud-hosted ScreenConnect panels, then executed remote commands to download malicious installers, write PowerShell scripts and batch files to disk, and spread laterally across managed networks.
Every stage of this attack required writing files to the Windows file system. That’s where it should have been stopped.
What Happened: File Writes All the Way Down
The attack unfolded in stages, but each stage depended on the same primitive operation: writing executable files to disk.
Initial payload delivery: Attackers used the ScreenConnect Run Command feature to execute curl.exe, which downloaded ScreenConnect.ClientSetup.msi from an attacker-controlled server (185.99.255[.]28) and saved it to C:\Windows\TEMP\sc.msi. Then msiexec.exe installed the rogue client silently.
Dropper and decoder deployment: The rogue client wrote a Base64-encoded batch file (sckit-run.bat) to disk, which contacted a remote server to fetch a PowerShell payload (sckit-decoder.ps1). That PowerShell script launched the SCKit malware toolkit.
Persistence and replacement: SCKit wrote additional scripts (TrapWatch.ps1, Panel-Lateral.ps1, Run-Lateral-Full.bat) and executables (ToolboxRelayUploader.exe, Sqlite3.exe) to disk, created scheduled tasks, added Defender exclusions, and replaced the legitimate ScreenConnect installation with an attacker-controlled copy.
Lateral movement: When a technician connected to an infected endpoint, the malware attempted to steal session cookies and spread to other ScreenConnect panels by writing malicious payloads to network shares and uploading them to the panel’s Shared Toolbox.
The attacker may have had valid credentials to the ScreenConnect panel, but credentials alone don’t encrypt files or steal data. The attacker needed to write executable code to disk on each target machine. That’s the choke point.
How FileSure Defend Stops This Attack
FileSure Defend operates at the Windows kernel level via a filter driver. It intercepts file system operations — open, read, write, create, delete, rename — before they reach the file system. Rules define which users, programs, and machines can perform which operations on which files.
For this attack, two rules would have stopped it cold.
Rule 1: Block delivery programs from writing executables
This rule prevents browsers, email clients, download utilities, and remote access tools from writing executable files to disk.
- File name filter:
*.exe;*.dll;*.msi;*.bat;*.cmd;*.ps1 - Program name filter:
curl.exe;powershell.exe;pwsh.exe;msiexec.exe - Operations: Write, Create
- Drive type: All local drives
- Result: Deny
When curl.exe attempts to write ScreenConnect.ClientSetup.msi to C:\Windows\TEMP\sc.msi, FileSure intercepts the write operation and blocks it. The file never lands on disk. The installer never runs. The rogue client never gets installed. The attack ends at the delivery stage.
When the batch dropper tries to write sckit-run.bat or sckit-decoder.ps1, FileSure blocks those writes too. No payload, no persistence, no lateral movement.
Rule 2: Block remote file writes to servers
This rule prevents lateral movement by blocking remote machines from writing executable files to local servers through SMB network shares.
- File name filter:
*.exe;*.dll;*.bat;*.cmd;*.ps1;*.msi - Program name filter:
REMOTE ACCESS(exact, case sensitive — this is a special FileSure keyword that matches any operation initiated by a remote machine over the network) - Operations: Write, Create
- Drive type: Hard drives
- Install type: Servers
- Result: Deny
When the attacker’s malware attempts to write lateral movement scripts or upload ToolboxRelayUploader.exe to a remote server’s Shared Toolbox via network share, FileSure blocks the write. Local processes on the server can write files normally. Remote machines — including compromised workstations — cannot write executables.
The attacker’s worm-like spread from endpoint to technician workstation to other endpoints depends entirely on remote file writes. FileSure cuts the chain.
Why This Works When Credential-Based Defenses Don’t
The security advice after this attack will focus on credential hygiene: use strong passwords, enable MFA, monitor for unusual logins, rotate API passphrases. That’s all correct, but it misses the point.
The attacker in this case likely had valid credentials — either stolen or hijacked from a legitimate session. MFA may have already been bypassed. The ScreenConnect panel believed the commands were authorized.
But even with valid credentials, the attacker still needed to write files to disk to do anything useful. Credentials give you access. File writes give you persistence, lateral movement, and damage.
FileSure enforces file access policies at the kernel level regardless of how the operation was initiated. It doesn’t care whether the ScreenConnect session is legitimate or compromised. It cares whether curl.exe is allowed to write an MSI file to the temp directory. The answer is no.
Control the file operations, and stolen credentials become far less useful.
Try It Yourself
FileSure Defend is free to try for 21 days — full functionality, no credit card required. Install it on a test machine, set up the rules above, and try to run curl.exe to download an installer. You’ll see the block happen in real time.
Start your free trial at bystorm.com.
Source: ScreenConnect Attacks Target at Least 288 Endpoints Across 48 Organizations With Rogue Clients
Category: Threat Intelligence
Tags: screenconnect, sckit malware, msp security, lateral movement, remote access abuse, kernel filter driver, file system security, rogue client deployment
