Huntress researchers have detailed a fast-moving campaign in which attackers abused cloud-hosted ScreenConnect panels to install rogue clients and a custom toolkit, dubbed SCKit, on managed endpoints. At least 288 hosts across 48 Huntress-protected organisations were affected within around 90 minutes on 11 November, with roughly a third compromised in the first ten minutes.
Rather than exploiting endpoints directly, the operator used ScreenConnect’s legitimate Run Command feature to execute commands as SYSTEM across many machines at once. Those commands silently installed an attacker-controlled ScreenConnect client, followed by a dropper that fetched a decoder and an encrypted 16-file package of PowerShell, batch and config files. Each package was encrypted with keys tied to the individual machine’s ID.
Hiding inside normal ScreenConnect traffic
At the core of SCKit is a component Huntress calls RelayTrap. It takes over the legitimate client’s connection slot on the relay, so the machine still appears healthy to the managing technician. The toolkit also stops the genuine client and sets it to manual start, adds Microsoft Defender exclusions, creates AppLocker/SRP rules and a scheduled task named TrapWatch for persistence, and installs a second attacker-controlled client.
Built to spread, not yet seen spreading
The code contains logic intended to move from an infected endpoint to the technician who connects to it. In theory, it steals the technician’s .aspxauth session cookie, replays it against the panel, enumerates reachable sessions, and uploads a payload to the panel’s Shared Toolbox to run as SYSTEM elsewhere, deleting the toolbox item around 60 seconds later.
Huntress stresses that this worm-like behaviour was largely reconstructed from code. The console-takeover attempt failed in every recovered host log it reviewed, and the firm has not confirmed a successful jump to a technician workstation or further endpoints.
ConnectWise published an advisory on the evening of 11 November and, as a precaution, disabled five third-party extensions across more than 400 partner environments. At the time of the advisory, the initial access vector and full scope had not been identified. Affected builds named in the research are 26.6.6.9747 and 26.7.6.9783.
What defenders should do
- Review ScreenConnect Run Command and Toolbox history for commands you did not initiate, and check endpoints for a second, unauthorised client.
- Triage suspect hosts out-of-band using EDR live response or WinRM, not ScreenConnect. Treat any technician workstation that has connected to a suspect host as potentially exposed.
- Isolate and clean affected hosts, removing the rogue client, the TrapWatch task, C:ProgramDataRelayTrap, SCKit files in %TEMP% and the RelayTrapLiteAlert Run key.
- End active ScreenConnect web sessions, rotate credentials, and revoke browser and identity-provider sessions.
- Use network IOCs from the report, but treat file hashes as weak indicators, as scripts are rebuilt per host.
Read the full Huntress research: https://www.huntress.com/blog/sckit-worm-rogue-screenconnect
