SCKit turns ScreenConnect into an attack platform: rogue clients, RelayTrap, and session-cookie theft. What happened and how MSPs can defend.
On November 11, 2026, ConnectWise reported an active campaign in which attackers gained unauthorized access to cloud instances of ConnectWise ScreenConnect — a remote-access and support platform massively used by managed service providers (MSPs) and IT teams to remotely administer and fix their clients' computers.
Having gained access to the management console, attackers used the built-in Run Command feature to mass-broadcast commands to managed devices. The commands quietly installed an additional "rogue" ScreenConnect client on customer machines, connected to the attackers' infrastructure, along with a new toolkit called SCKit. This means even after a legitimate support session ended, the attackers kept a separate, private remote-access channel to infected systems.
The scale is striking in its speed. Per Huntress, on November 11 alone the operator hit at least 288 hosts across 48 organizations, roughly a third of them in the first 10 minutes. On November 13, Huntress recorded a fresh spike from different infrastructure hitting another 205 hosts across 41 organizations. ConnectWise responded by preemptively disabling five third-party extensions in over 400 partner environments.
How SCKit works: a 16-file kit
SCKit isn't one program but a package of 16 files: PowerShell scripts, batch scripts, .cmd files, and configuration data assembled into a multi-stage spread mechanism. The kit's job is to persist, keep access, and spread further through the very infrastructure an MSP uses to manage its clients.
Delivery is cleverly organized. The payload is stored encrypted, but the decryption key is effectively provided by the infected machine itself: when the worm requests the package from the attackers' infrastructure, it passes the Windows system's GUID in the query string. The server returns the encryption key, initialization vector, and salt, with which the script unpacks the package into that machine's temp folder. So each SCKit copy is bound to a specific device — complicating analysis and reuse of an intercepted artifact on another machine.
After unpacking, traps and blocking policies are installed, and the installer adds Windows Defender exclusions and installs a second, attacker-controlled ScreenConnect client. The legitimate ScreenConnect client is stopped and switched to manual start — replaced by the attackers' copy. All this runs with SYSTEM privileges, so ordinary antivirus and updates alone don't save you.
RelayTrap: a support session in reverse
The most interesting part of SCKit is RelayTrap, which flips the usual remote-support logic upside down. Normally a technician uses a Host client to connect to a remote system with a Guest component, to interact with it, transfer files, and perform administrative actions. SCKit tries to reverse that connection — to make the infected customer machine attack the technician when they connect for support.
RelayTrap is implemented not as a ready binary but as C# source — the RelayTrap.cs file. It's uploaded to the infected device, where a PowerShell script compiles it into a local executable. A separate TrapWatch component watches ScreenConnect services and prepares a replacement for the legitimate Guest process. When a technician opens an interactive support session, RelayTrap waits 2.5 seconds after the connection establishes and tries to push back to the technician's workstation a file Run-Lateral-Full.bat set to execute.
Blackpoint Cyber and Huntress researchers noted a telling detail: RelayTrap's source contains extremely detailed comments explaining its functionality, compatibility workarounds, and even prior coding mistakes. This is the typical signature of code generated by a large language model. So the attackers most likely accelerated the worm's development with AI — another confirmation that code-generation tools are actively used offensively.
Cookie theft and pivoting to other clients
If RelayTrap successfully delivers its payload to the technician's workstation, stage two begins — moving from the infected machine to the entire client fleet that technician manages.
The Panel-Lateral.ps1 component (with support from LabConfig.ps1) steals the .aspxauth session cookie from the technician's browser and tries to replay it against the ScreenConnect console. This lets attackers hijack an already-authenticated management session — without knowing the password and without re-passing MFA. Then the ToolboxRelayUploader.exe tool uses that access to upload WithUninstall.ps1 into the Shared Toolbox, and a panel command forces every reachable session to run it with SYSTEM rights. About 60 seconds after broadcast, ToolboxRelayUploader removes the item from Shared Toolbox to cover its tracks.
So a worm-like infection chain builds up: compromised client machine → technician's workstation → other endpoints in every organization that technician can reach. In an MSP environment, where one technician may administer dozens of clients, this means a potential path to compromising many unrelated companies at once through the very infrastructure servicing them.
An important caveat: no research team has yet observed a successful jump from a client machine to a technician's workstation. Blackpoint Cyber's testing against the current ScreenConnect client showed Guest queued the transfer, but the technician-side Host never requested or ran the file. In other words, spread "via the technician" is a designed capability of the toolkit that an already-released patch prevented from being realized — not a confirmed infection.
The role of CVE-2026-84869 and third-party extensions
At the center of the Guest-to-Host mechanism lies CVE-2026-84869 — a critical client-side ScreenConnect flaw rated 9.9 CVSS. It allowed unauthorized file transfer and execution during an active remote session under certain conditions. ConnectWise shipped the fix back on September 8, 2026 in client version 26.6.5.
Here lies the first practical trap for MSPs: updating the cloud console doesn't automatically update technicians' clients. Many partners still run old client versions vulnerable to CVE-2026-84869 — which is why ConnectWise stresses all technician clients must be checked for version 26.6.5 or newer.
The second problem is third-party extensions. ConnectWise identified five independent extensions potentially linked to this activity and preemptively disabled them in hundreds of partner environments:
- Labtech Plus
- RMM Plus
- RMM+
- RMM Plus Password Link
- RMM+ Password Link
Separately, researchers reported an authentication flaw in RMM+ 1.0.31 and 1.0.32 that could accept an empty access key if none was configured. ConnectWise said at publication the initial access vector hadn't been established yet — the path by which attackers first entered partner consoles is still being determined. For on-premises owners, the recommendation is firm: immediately disable the listed extensions and ensure all technician clients are updated.
Why this is dangerous specifically for MSPs
This attack is valuable not so much for technical complexity as for target choice. An MSP is a multiplier: one compromised management console opens access to dozens or hundreds of client organizations at once. Attacking a service provider is more profitable than attacking each company separately — the same principle as supply-chain attacks.
Moreover, ScreenConnect is a legitimate tool trusted by defenses and administrators. Commands broadcast via Run Command and extra ScreenConnect clients look like normal activity, so they're easy to miss. Huntress researchers warn directly: removing just the "extra" client doesn't remove the toolkit's persistence — infected systems were re-infected shortly after being restored without full cleanup.
Finally, the session-cookie theft via Panel-Lateral.ps1 is a classic identity attack that bypasses passwords and MFA. If a technician is authorized, the attacker doesn't need their credentials — a stolen session token suffices to act on their behalf.
How to protect yourself: practical steps
ConnectWise and research teams laid out a concrete action plan for MSPs and IT teams. Even if you received no compromise notices, check the environment now.
1. Disable third-party extensions and update clients. On-premises owners must immediately disable Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, and RMM+ Password Link. All ScreenConnect technician clients must run 26.6.5 or newer — remember the cloud-console update doesn't auto-update clients.
2. Don't connect to a suspicious host via ScreenConnect. An interactive session can provoke a spread attempt to the technician's workstation. For investigation, use EDR live response, WinRM, or another out-of-band tool. If a technician already connected to a suspicious host, treat their workstation as potentially compromised and investigate from a clean device.
3. Isolate the host until fully cleaned. Isolation alone doesn't remove persistence. Delete the rogue client, the TrapWatch scheduled task, the C:\ProgramData\RelayTrap\ folder, the RelayTrapLiteAlert value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, plus toolkit files in %TEMP% (notably sckit-*, Panel-Lateral.ps1, runnew.cmd, ToolboxRelayUploader.exe). Verify the legitimate client separately before deleting anything.
4. Revoke compromised access. From a clean device, end active ScreenConnect web sessions and change credentials. Since the toolkit steals browser-session tokens, also revoke potentially compromised browser and identity-provider sessions. Worth reminding: if you suspect accounts fell into attackers' hands, check them for leaks — for example, via our data-breach check tool.
5. Audit panel activity. Review Run Command and Toolbox logs for unknown executions and tools, and use instance audit logs to determine which systems and technician workstations may have been accessed. Watch for sudden mass activity nobody on your team initiated.
Conclusion
SCKit is a telling example of attackers targeting not individual companies but the service providers that serve them all. A legitimate remote-support tool was turned into an attack platform, and the deployment speed — hundreds of hosts in minutes — is a reminder that in such scenarios the clock runs in hours.
For MSPs, the main lesson is not to blindly trust your own tooling. Check client versions, keep third-party extensions under control, audit Run Command and Toolbox, and investigate suspicious hosts only with out-of-band means. And remember: removing the "extra" client isn't enough — SCKit's persistence lives deeper, and without full cleanup the system returns to the attackers' control.
