Attackers with access to cloud-hosted ConnectWise ScreenConnect panels used the built-in Run Command feature on November 11 to install rogue remote-access clients and a custom toolkit called SCKit on at least 288 managed endpoints across 48 organizations, according to Huntress. ConnectWise disabled five third-party extensions across roughly 400 partner environments as a precaution. If you run ScreenConnect, or rely on a managed service provider (MSP) that does, review your panel history now and avoid opening sessions to suspect machines.
What happened
Huntress says it first saw the activity at about 17:47 UTC on November 11. All 288 hosts were hit within roughly 90 minutes, about a third of them in the first ten. SecurityWeek, citing Huntress, reports that at least six MSPs were involved, and The Hacker News says Sophos has seen the same pattern of unauthorized ScreenConnect client installs.
On each machine, the commands ran as SYSTEM, silently installed an attacker-controlled ScreenConnect client, and fetched SCKit, a package of 16 PowerShell, batch and configuration files. Huntress says the kit adds Microsoft Defender exclusions, installs a second rogue client, creates a scheduled task named TrapWatch, and swaps the legitimate ScreenConnect client for the attacker’s copy.
SCKit is also built to spread. According to Huntress’s code analysis, when a technician connects to an infected machine, the toolkit is designed to steal that technician’s ScreenConnect session cookie, replay it against the panel, and push a payload to every session the technician can reach. Huntress stresses this was reconstructed from the code, not observed: it has not seen a successful jump to a technician workstation, and the panel takeover attempt failed in every host log it has checked so far.
Who is affected and why it matters
The direct victims are customers whose machines are managed through the affected panels. ConnectWise says about 400 partner environments had at least one of five extensions installed: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. It stresses that having one installed does not mean a network was compromised, and says it has found no ScreenConnect vulnerability and no breach of its own infrastructure. In our analysis, the lesson is reach: one compromised panel can run commands on every endpoint it manages, so a single MSP incident can touch many customers at once.
What to do
These steps come from Huntress and ConnectWise unless marked as our analysis.
- Audit ScreenConnect Run Command and Toolbox history for executions you did not start, and check managed endpoints for an unauthorized second ScreenConnect client.
- Do not open a ScreenConnect session to a suspect machine. Use EDR live response, WinRM or another out-of-band tool, and treat any technician workstation that already connected as exposed.
- Isolate infected hosts and keep them isolated until cleaned; Huntress saw systems reinfect after isolation was lifted. Remove the rogue client service, the TrapWatch task, the RelayTrap folder under ProgramData and the RelayTrapLiteAlert Run key.
- On self-hosted ScreenConnect, disable the five extensions yourself; ConnectWise has urged on-premises partners to do so.
- From a clean device, end active ScreenConnect web sessions, rotate ScreenConnect credentials, and revoke browser and identity-provider sessions that may have been exposed.
- Our analysis: keep the extensions off until ConnectWise says otherwise, require MFA on every technician login, and hunt for the IP addresses, domains and file names ConnectWise and Huntress published.
What we still do not know
ConnectWise’s advisory, as quoted by The Hacker News, says “The initial access method and full scope remain under investigation.” Huntress told that outlet it has seen no evidence of a new vulnerability and that its telemetry points to compromised credentials or hijacked operator sessions. Huntress’s own post says the activity appears tied to the RMM+ extension, and SecurityWeek, quoting Huntress, reports that attackers likely abused RMM+ versions 1.0.31 and 1.0.32, which accept a blank access key if none was ever configured. ConnectWise had not confirmed that explanation in the reports we reviewed.
The Hacker News also reports that the attacker tagged each compromised MSP with a sequential number, and the tags Huntress saw start partway through the sequence, which suggests other MSPs may have been hit earlier. None of the reports we reviewed names the attacker.
Sources: Huntress (Nov 11, 2026); The Hacker News (Nov 12, 2026); SecurityWeek (Nov 12, 2026).
Leave a Reply