Huntress is tracking an active campaign against managed service providers running on-premises ConnectWise ScreenConnect with the third-party RMM+ extension installed. Attackers abuse an authentication flaw in the extension to call ScreenConnect’s Run Command feature against every endpoint the MSP manages. Through that, they install a second ScreenConnect client that they control, plus a toolkit Huntress calls SCKit.

The first wave started on November 11, 2026. It hit 288 endpoints across 48 Huntress-protected organizations within about 90 minutes, roughly a third of them in the first ten minutes. On November 13 Huntress saw a second spike from new attacker infrastructure: 205 more hosts across 41 organizations. These counts cover only Huntress customers, so the real number is higher.

Root cause: an empty key that counts as a valid key

RMM+ exposes an API that sits beside ScreenConnect’s own authentication. It does not use ScreenConnect user accounts, roles or MFA. Callers authenticate with a single shared secret stored in the extension’s RMMPlus.AccessKey setting.

In RMM+ 1.0.31 and 1.0.32, that setting defaulted to empty, and the extension accepted an empty key as a match. On any server where an admin installed RMM+ and never set a key, anyone who could reach the ScreenConnect web interface could use the API without credentials. From there the attacker could push commands to every attached session.

ConnectWise says it has found no vulnerability in ScreenConnect itself and no compromise of its own infrastructure. It says the API is protected by a passphrase the partner sets during setup. That is the gap: the passphrase was optional, and a blank one passed the check. ConnectWise and the RMM+ developer both tell on-prem customers to disable the extension. None of the reporting so far names a fixed RMM+ release.

What SCKit does on the endpoint

Once a host receives the Run Command payload, SCKit sets up a persistent channel that is hard to spot:

  • Second client: It installs an attacker-controlled ScreenConnect client. Huntress lists rogue client IDs 2588ef5c15954b10 and ed630cc2c873b091.
  • Disables the real client: It stops the legitimate client and sets its service to manual start.
  • RelayTrap: A relay listening on port 81 (tied to client ed630cc2c873b091) takes over the legitimate client’s connection slot. The technician’s console still shows the machine as online and healthy.
  • Defense tampering: It adds Microsoft Defender exclusions and creates AppLocker/SRP rules.
  • Persistence: It creates a scheduled task named TrapWatch, a RelayTrap folder, and a RelayTrapLiteAlert Run key. A Lite-Alert.ps1 script logs ScreenConnect file-run events and new client service installs, which tells the operator when a defender is acting.
  • Cookie relay (the worm part): SCKit tries to capture ScreenConnect session cookies when a technician next connects. The aim is to hijack the technician’s authenticated console session without credentials or a new MFA prompt, then move into other MSP customers.

The worm stage has not been seen working. Every console-takeover attempt failed in the host logs Huntress recovered, and Blackpoint reports the cookie relay failed against a patched ScreenConnect client. The design still targets the most dangerous asset an MSP has: a technician session that reaches every customer.

Huntress notes that SCKit scripts are rebuilt for each host, so file hashes are weak indicators. Hunt on behavior and the client IDs instead. Some isolated machines were reinfected once isolation was lifted, which means remote cleanup alone is not reliable.

Who is affected

This affects MSPs and internal IT teams running self-hosted ScreenConnect with RMM+ 1.0.31 or 1.0.32 and no access key configured. Every endpoint behind such a server should be treated as exposed. Removing the extension or rotating passwords does not remove rogue clients already installed on endpoints.

One vendor writeup links the campaign to CVE-2026-84869, the ScreenConnect client missing-authorization flaw (CVSS 9.9, in CISA KEV since September). That flaw lets files be transferred and run during a session without host approval. No other source confirms this link. Even so, clients below 26.6.5 should already have been upgraded.

What to do now

  1. Disable RMM+ and any similar third-party extensions on on-prem ScreenConnect servers. Keep them off until a fixed version is confirmed.
  2. Audit extension settings for empty or default shared secrets, and limit network access to the ScreenConnect web interface (VPN, IP allowlist).
  3. Review Run Command history from November 11 onward for commands you can’t account for, especially ones sent to many sessions at once.
  4. Hunt for a second ScreenConnect client on every managed endpoint. Look for the rogue client IDs above, a legitimate client service switched to manual start, a TrapWatch scheduled task, a RelayTrap directory, a RelayTrapLiteAlert Run key, unexpected Defender exclusions, new AppLocker/SRP rules, and listeners on TCP/81.
  5. Isolate, then clean or reimage affected hosts. Confirm the host stays clean after isolation is lifted.
  6. End all ScreenConnect web sessions, rotate technician credentials, and revoke browser and IdP sessions, since session cookies were the target.
  7. Upgrade ScreenConnect clients to 26.6.5 or later and reinstall host clients and access agents, per ConnectWise’s CVE-2026-84869 bulletin.

References