Blank default key in ScreenConnect RMM+ extension let attackers reach 288 endpoints

Rogue remote-access clients deployed at speed

On November 11, 2026 at 17:47 UTC, unknown operators began issuing commands through cloud-hosted ScreenConnect panels belonging to managed service providers. According to Huntress, the researchers who detected and analyzed the campaign, at least 288 endpoints across 48 organizations received attacker-controlled remote-access clients within 90 minutes, and roughly a third of those machines were hit in the first ten minutes. ConnectWise, ScreenConnect's vendor, published an advisory the same day at 22:45 UTC identifying five third-party ScreenConnect extensions as possibly associated with the activity and disabled them across roughly 400 partner environments as a precaution. The company stressed that having one of the extensions installed was not in itself evidence of a breach.

The entry point was an empty setting

Huntress's updated analysis ties the activity to one of the five: an extension called RMM+, built to let external tools drive ScreenConnect sessions without a technician at the console. To do that, it skips past ScreenConnect's own user accounts, roles and multi-factor authentication, and instead authenticates callers with a shared access key stored in its settings. In versions 1.0.31 and 1.0.32 that key defaulted to empty, and the authentication code accepted an empty value, so a caller presenting no credentials at all could pass, even though the setting's own description urged administrators to configure a strong key. Huntress notes the observations fit this route: commands reached endpoints across several ScreenConnect instances within minutes, with no corresponding logins, and the executions appear in logs linked to RMM+. This was not memory corruption or a phishing lure, but an unset configuration default, and it lived in an extension rather than in ScreenConnect's core code.

SCKit and RelayTrap on the endpoint

The delivered payload, a sixteen-file bundle of PowerShell, batch scripts and configuration data dubbed SCKit, is keyed to each victim machine: the infected host sends its Windows machine GUID in the request URL, and the server returns the decryption key, initialization vector and salt in response headers. Every copy is therefore rebuilt with different embedded values, and Huntress warns that file hashes are weak indicators here, since the trap executable is compiled separately on each host.

On the machine, the sequence downloads a rogue installer to C:\Windows\TEMP\sc.msi, unpacks the toolkit to C:\ProgramData\RelayTrap, adds Microsoft Defender exclusions and installs a second, attacker-controlled ScreenConnect client. A script named TrapWatch, running as SYSTEM, compiles a C# component called RelayTrap into a host-specific executable and registers a scheduled task. The legitimate ScreenConnect client is then stopped and set to manual start while the attacker's copy takes over its relay connection, so the machine still looks like it is running ordinary ScreenConnect. Huntress also notes that the RelayTrap source carries unusually detailed explanatory comments, which the researchers say suggests it may have been generated with a large language model.

A worm by design, not in practice

SCKit was built to spread. Two and a half seconds after a technician connects to a compromised host, the trap pushes a dropper to the technician's machine. A script then steals the technician's .aspxauth session cookie and tries to replay it against the panel to enumerate every session they can reach, while another component plants a payload in the panel's Shared Toolbox, triggers every reachable session to run it as SYSTEM, and deletes the item about a minute later to cover its tracks. The toolkit even keeps a skip list so it avoids infecting the attacker's own panel. Huntress, however, found no evidence that any of this lateral movement succeeded: the console-takeover attempt failed in every recovered host log, and what actually spread was the panel-side command abuse. The defensive guidance follows from the design. Do not triage a suspect host over ScreenConnect, since an interactive session is exactly what the trap waits for; use an out-of-band channel such as EDR live response or WinRM, and treat any technician workstation that connected as exposed.

Why isolating an infected host is not enough

Huntress observed systems being reinfected shortly after network isolation was lifted, because isolating a machine does not remove the persistence. Cleanup requires deleting the rogue client service, the TrapWatch scheduled task, the RelayTrap directory, the toolkit files in %TEMP% and a Run-key value named RelayTrapLiteAlert, then verifying the machine stays clean. Because the toolkit bundles sqlite3 to read browser cookie databases, potentially exposed browser and identity-provider sessions should be revoked, and ScreenConnect credentials rotated from a clean device. Finally, panel audits of Run Command and Toolbox history will reveal executions nobody initiated.

Why it matters

The incident extends a pattern documented by BleepingComputer and Huntress earlier in 2026: in September, Huntress responded to similar worm-like activity spawning rogue ScreenConnect clients, and ConnectWise patched CVE-2026-84869, a critical file-transfer vulnerability rated 9.9. November adds a sharper lesson. A legitimately installed extension inherited the platform's trust while bypassing its accounts and MFA, and the single setting standing between an anonymous caller and control of hundreds of endpoints shipped empty. Management-plane access of that kind turns one misconfiguration into a multi-organization incident in minutes, and the tooling behind it appears increasingly to be assembled with AI assistance.