Hijacked ConnectWise ScreenConnect panels push SCKit worm to 288 hosts

A threat actor with access to several cloud-hosted ConnectWise ScreenConnect panels used them on 11 November to install rogue remote-access clients and a toolkit called SCKit on managed computers, according to a technical write-up by Huntress. Huntress counts at least 288 affected hosts across 48 organisations among its own customers, all hit within 90 minutes of the first activity at about 17:47 UTC, and about a third of them in the first 10 minutes. ScreenConnect is the remote support tool many managed service providers use to run commands on their clients' machines, so one panel can reach many organisations.

ConnectWise said in an advisory posted at 22:45 UTC that it had identified five independent third-party extensions that may be associated with the activity: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. It disabled them as a precaution in about 400 partner environments, and on-premises partners have to disable them themselves. ConnectWise has not identified the initial access vector or the full scope.

How the toolkit takes over a machine

Huntress says the operator used the panels' Run command feature to send one command to many endpoints at once, running as SYSTEM. The command installed an attacker-controlled ScreenConnect client and dropped a script that fetched SCKit, a 16-file package of PowerShell and batch scripts encrypted separately for each machine using the Windows system ID.

The kit compiles a program called RelayTrap on each host, sets a scheduled task to run every 10 seconds, adds Defender exclusions, installs a second rogue client and stops the legitimate ScreenConnect client so the attacker's copy can take its place on the real relay, keeping the machine looking normal. Huntress says the RelayTrap source code appears to have been generated by an AI model, judging by its detailed comments.

Built to spread through technicians

The kit also contains code designed to spread further, which is why Huntress calls it a worm. When a technician connects to an infected machine, the kit is meant to push a dropper back to the technician's workstation, steal the ScreenConnect session cookie from the browser, replay it against the panel, place a payload in the panel's Shared Toolbox and tell every session the technician can reach to run it, deleting the toolbox item about a minute later.

Huntress stresses that it has not seen this step succeed: the console takeover failed in every recovered log it has checked so far, and the 288 infections it observed came from the operator's own Run commands.

What responders should do

Huntress's main advice is not to connect to a suspected host through ScreenConnect, and to use EDR live response, WinRM or another out-of-band tool instead; any technician workstation that has already connected should be treated as exposed. It advises isolating affected hosts until clean-up is complete, because systems have reinfected shortly after isolation was lifted; removing the rogue client, the TrapWatch task, the C:\ProgramData\RelayTrap folder and the RelayTrapLiteAlert Run key; ending ScreenConnect web sessions and rotating credentials from a clean device; and auditing Run Command and Toolbox history. Its write-up includes indicators of compromise.

Huntress responded to similar worm-like rogue ScreenConnect activity in September, after which ConnectWise fixed a critical file-transfer flaw, CVE-2026-84869. Neither company has linked the two campaigns, said how the operator got into the panels, or named the developers of the five extensions.