Rogue ScreenConnect Clients Hit 288 Endpoints via RMM+ Flaw

Attackers pushed rogue copies of ConnectWise ScreenConnect onto at least 288 managed computers at 48 organizations on November 11, 2026, according to security firm Huntress, which watched the whole wave land in about 90 minutes. The commands came through cloud-hosted ScreenConnect panels run by managed service providers, and Huntress later tied them to RMM+, an add-on from an outside developer that, in two versions, let callers in with an empty access key. ConnectWise said it had found no flaw in ScreenConnect and no breach of its own systems. As a precaution, it switched off five related extensions in roughly 400 partner environments.

Huntress first saw the activity at about 17:47 UTC. Roughly a third of the affected hosts were hit in the opening ten minutes. In its write-up, researchers Ben Nahorney and Susannah Matt said an operator used the panels' Run command feature to send instructions to many endpoints at once, executing as SYSTEM. Each command looked for an existing ScreenConnect client, fetched an installer controlled by the attacker, installed it silently and dropped a small encoded batch file. Sophos reported the same sequence in a separate alert: curl pulled the installer from an attacker server, msiexec installed it without prompts, and PowerShell, with its execution policy bypassed, retrieved a second-stage script. Sophos traced the commands to three ScreenConnect instances it believed were compromised.

The second stage was a kit Huntress calls SCKit, a bundle of 16 scripts, batch files and configuration files. It arrives encrypted. The infected machine sends its own Windows identifier to the attacker's server and gets back the values needed to unlock a copy built for that host. Once unpacked, the kit added Microsoft Defender exclusions, installed a second rogue ScreenConnect client and created a scheduled task called TrapWatch that runs as SYSTEM. It then stopped the genuine ScreenConnect service, set it to start manually and lined up the attacker's copy to take its place. Huntress said the C# code for one component, a program it named RelayTrap, looked as though a large language model had written it, judging by its detailed comments.

The kit was also built to travel further, though Huntress stressed it had not seen this part work. When a technician opens a session to an infected machine, a file transfer fires about 2.5 seconds later and hands the technician's workstation a dropper. From there, the code tries to lift the browser cookie that keeps the technician signed in to the panel, reuse it, list every session that technician can reach, and place a payload in the panel's Shared Toolbox. A single request would then tell all of those endpoints to run it, and the item would be deleted about a minute later. Huntress said the console takeover step failed in every recovered host log it had reviewed. The Hacker News reported that the attacker tagged each compromised MSP with a sequential number and that the tags Huntress saw began partway through the count, a sign other providers may have been hit earlier.

The entry point came into focus late on November 11. Huntress said RMM+ lets another tool drive ScreenConnect sessions without a technician at the console, skipping ScreenConnect's own accounts, roles and multifactor prompts in favor of a shared key held in the extension's configuration. Two releases, 1.0.31 and 1.0.32, shipped with that key empty by default, and the check did not reject a blank value. Commands reached endpoints in several instances within minutes, with no matching logins, and logs tied them to RMM+. Most installations Huntress found were legitimate, typically added for a project and never removed.

ConnectWise published its advisory at 22:45 UTC that day. The company said the mere presence of the extensions did not prove compromise, that on-premises customers had to disable them themselves, and that it had no view into what happened inside partner environments after initial access. It warned that turning off extensions and resetting credentials might not remove footholds already planted on endpoints. Huntress added that isolated machines had been seen reinfecting shortly after isolation ended, and advised against connecting to a suspect host over ScreenConnect at all, recommending EDR live response or WinRM instead.

The incident underscores how much exposure an organization inherits through its managed service provider's remote access tools, including plug-ins nobody remembers installing. IT auditors and GRC teams at banks, insurers and enterprises can ask their MSPs whether ScreenConnect panels run any third-party extensions, which versions, and who approved them, and should request evidence that the listed add-ons were disabled. Run Command and Toolbox history deserve review even without an alert, as do any second ScreenConnect client on managed machines and the scheduled task Huntress named. Contracts and oversight reviews should confirm that vendor tools cannot bypass multifactor authentication, that unused integrations are removed on a set schedule, and that the provider will report suspicious panel activity promptly. Because the kit was designed to steal session cookies, revoking browser and identity provider sessions belongs in any response plan alongside password resets.