On November 11, 2026, at 17:47 UTC, someone started pushing commands through cloud-hosted ScreenConnect panels belonging to managed service providers. Within 90 minutes, at least 288 endpoints across 48 organizations had been fitted with attacker-controlled remote access clients. About a third of them fell in the first ten minutes.

That speed is the headline. The mechanism underneath it is more instructive, and researchers at Huntress, who detected and dissected the campaign, have now published a full technical account. This article is based on Huntress's analysis and BleepingComputer's reporting. Statements from the ConnectWise advisory are cited through those sources; the advisory was not consulted directly. Here is what the attack actually was, and what it teaches.

The door was a default that stayed blank

ConnectWise's advisory, posted at 22:45 UTC on November 11, said the company had identified five third-party ScreenConnect extensions that might be associated with the activity and disabled them across roughly 400 partner environments as a precaution. In its later update, Huntress says the activity seems related to one of them: an extension called RMM+.

RMM+ exists to let other tools drive ScreenConnect sessions without a technician using the console. It bypasses ScreenConnect's own user accounts, roles, and multi-factor authentication, and instead authenticates requests with a shared access key stored in the extension's settings. In versions 1.0.31 and 1.0.32, that key defaulted to blank. The setting's own description told administrators to "set a strong key," but if nobody ever did, the authentication check accepted an empty value. A caller with no credentials at all could pass.

Huntress's updated analysis points to an initial-access route through the extension: not a memory corruption bug, not a phishing page, but a password field that shipped empty and a code path that treated empty as acceptable. Huntress notes the observations matched: commands reached endpoints across several ScreenConnect instances within minutes, with no corresponding login activity, and the commands appeared in logs linked to RMM+.

It is worth being precise about one thing. ConnectWise stressed that having one of these extensions installed does not mean a network was compromised, and that disabling them was precautionary containment, not evidence that existing compromise had been removed. Earlier reporting also emphasized that the campaign abuses legitimate functionality rather than exploiting a classic software vulnerability. Both framings are true, and both matter: the flaw lives in an extension's default configuration, not in ScreenConnect's core code.

What SCKit does once it lands

The toolkit delivered through those Run commands is called SCKit: sixteen files of PowerShell, batch scripts, and configuration data. The delivery has a detail worth pausing on. The package arrives encrypted, and the delivery script receives the decryption values from the server. When an infected machine requests the kit, it passes its own Windows machine GUID in the URL's query string, and the server returns the decryption key, initialization vector, and salt in the response headers. Each machine gets a package keyed to itself, which is why Huntress warns that file hashes are weak indicators here: the scripts are rebuilt with different embedded values, and the trap executable is compiled separately on every host.

On the endpoint, the sequence looks like this. The initial command checks for an existing ScreenConnect client, then downloads an attacker-controlled installer to C:\Windows\TEMP\sc.msi and installs it silently. A dropper pulls down the keyed toolkit and unpacks it to C:\ProgramData\RelayTrap. An installer adds Microsoft Defender exclusions and installs a second rogue ScreenConnect client. A script named TrapWatch, running as SYSTEM, compiles a C# program called RelayTrap into a host-specific executable and registers a scheduled task. Then the legitimate ScreenConnect client is stopped and set to manual start, and the attacker's copy slides into its connection slot on the relay. To anyone glancing at the machine, ScreenConnect still appears to be there and normal.

One more observation from the Huntress analysis deserves quoting carefully: the C# source of RelayTrap carries detailed comments explaining exactly what each part is intended to do, which the researchers say suggests it was generated by an LLM. Attack tooling written by AI is no longer a prediction; in this campaign it is a reasonable inference from the code itself.

The part that did not work, and why it still matters

SCKit was built to be a worm, not just a backdoor. The designed path runs from an infected endpoint to any technician who connects to it, and from that technician's workstation to every other endpoint their ScreenConnect panel can reach. Two and a half seconds after a technician connects, the trap pushes a dropper to their machine. A script steals the technician's .aspxauth session cookie and tries to replay it against the panel to enumerate every session they can access. Another component uploads a payload to the panel's Shared Toolbox, triggers every reachable session to run it as SYSTEM, and deletes the toolbox item roughly sixty seconds later to cover its tracks. The malware even keeps a skip list so it does not infect the attacker's own panel and machines.

Here is the honest caveat, which separates observed activity from capability: Huntress says it has not observed this lateral mechanism succeed. The console-takeover attempt failed in every recovered host log the researchers checked. The worm's teeth, as deployed on November 11, did not bite. What spread was the panel-side Run command abuse, not the self-propagation.

That does not make the design academic. It tells you what the operator wanted, and the defender guidance follows directly from it: do not triage a suspected host over ScreenConnect, because an interactive session is exactly what the trap is waiting for. Use EDR live response, WinRM, or another out-of-band channel, and if a technician already connected, treat their workstation as exposed and investigate it from a clean device.

Isolation is not cleanup

The mitigation guidance contains another point that runs against instinct. Isolating an affected host does not remove the persistence, and Huntress observed systems reinfecting shortly after isolation was lifted. Cleanup means removing the rogue client service, the TrapWatch scheduled task, the RelayTrap directory and the toolkit files in %TEMP%, and a Run-key value named RelayTrapLiteAlert, then checking for reinfection before the machine goes back into service. Because the toolkit reads browser cookie databases with a bundled copy of sqlite3, potentially exposed browser and identity-provider sessions should be revoked too, and ScreenConnect credentials rotated from a clean device. Finally, audit the panel itself: Run Command and Toolbox history will show executions nobody initiated.

The actual lesson

This campaign sits on top of an earlier warning. In September 2026, Huntress responded to similar worm-like activity spawning rogue ScreenConnect clients, and ConnectWise patched a critical file-transfer vulnerability, CVE-2026-84869, rated 9.9. The November figures show how management-plane access can reach hundreds of endpoints across dozens of organizations in a short period.

But the November 11 incident adds something new to that picture. Huntress's updated analysis points to an extension, often legitimately installed for a project and left in place, whose security model bypassed the platform's accounts and MFA, and whose single protective setting shipped blank. The description field said to set a strong key. The default said otherwise, and the code obeyed the default.

Defaults are attack surface. Extensions inherit your trust but not your controls. And when the remediation guide for an incident starts with "do not connect to the infected machine with the tool you use to connect to machines," the industry has a design problem, not just an attacker problem.

Sources: Huntress, "SCKit Worm Installs Rogue ScreenConnect Clients and Session Cookie Relays Across Hundreds of Endpoints" (Ben Nahorney, Susannah Matt, November 11, 2026, updated 11:34 PM ET); BleepingComputer, "Active ScreenConnect attacks breach MSPs, impact dozens of organizations" (Lawrence Abrams, November 11, 2026), including statements from the ConnectWise advisory of November 11, 2026.