Rogue ScreenConnect clients pushed through MSP panels

On the afternoon of Wednesday, November 11, 2026, someone used the Run Command feature in several MSPs' cloud-hosted ScreenConnect panels to install a second, attacker-controlled ScreenConnect client on their clients' machines. No ScreenConnect vulnerability is involved so far. The leading theory is a third-party extension that can skip logins. If you run ScreenConnect, check your Run Command history today, even if nothing has alerted.

Huntress saw 288 endpoints hit in about 90 minutes

Huntress first saw the activity at about 17:47 UTC on November 11, across several ScreenConnect environments at once. About a third of the affected hosts were hit in the first ten minutes. Within roughly 90 minutes, 288 endpoints at 48 Huntress-customer organizations were affected. Huntress saw the activity on ScreenConnect versions 26.6.6.9747 and 26.7.6.9783.

Earlier counts were six compromised MSPs and 286 endpoints, as reported by BleepingComputer. Huntress said the numbers were still rising. It also noted that the attacker numbered its installs in sequence, which suggests other MSPs were hit before this wave.

The commands came through a legitimate feature, not an exploit

The operator ran commands as SYSTEM on many endpoints at once from the MSPs' own panels. Those commands installed a rogue ScreenConnect client and a toolkit Huntress calls SCKit. The toolkit is 16 PowerShell, batch and config files, delivered encrypted, with a decryption key tied to each machine.

SCKit digs in. It takes over the legitimate ScreenConnect client's relay slot, adds a scheduled task and a Run key, adds Defender exclusions, and writes AppLocker or software restriction rules.

It also carries code meant to spread. When a technician connects to an infected host, the code tries to steal the technician's ScreenConnect session cookie and use it to push a payload to every session that technician can reach. Huntress says it has not seen that spread succeed. The takeover attempt failed in every host log it reviewed so far. ConnectWise says it has reports of technician workstations compromised during interactive sessions, which it is still verifying.

A third-party extension is the leading suspect

ConnectWise's advisory, first published at 22:45 UTC on November 11, says it has found no compromise of its own infrastructure and no ScreenConnect vulnerability. It suspects abuse of independent third-party extensions. About 400 partner environments had at least one of these installed:

Labtech Plus
RMM Plus
RMM+
RMM Plus Password Link
RMM+ Password Link

ConnectWise disabled them where it could and is contacting all partners. On-premises partners must disable them themselves.

Huntress goes further, as analysis rather than confirmed cause. RMM+ authenticates with a shared access key instead of user accounts, roles and MFA. In RMM+ versions 1.0.31 and 1.0.32, that key defaults to blank, and an empty value is accepted if none was set. The setting is RMMPlus.AccessKey. In this incident, commands appeared in logs tied to RMM+ with no matching login.

Timeline

Date and time (UTC)	Event
November 11, about 17:47	Huntress sees mass Run Command activity across several ScreenConnect environments
November 11, within 10 minutes	About one-third of the 288 hosts are affected
November 11, within about 90 minutes	All 288 hosts are affected
November 11, 22:45	ConnectWise publishes its advisory and disables the five extensions
November 12, 02:45	ConnectWise updates its advisory
November 12, about 03:34	Huntress links RMM+ to the activity

Who is exposed

Any MSP running ScreenConnect with one of the five extensions installed, cloud or on-premises. On-premises instances are at most risk, because ConnectWise could not disable the extensions for them. ConnectWise says partners without these extensions have no reason to believe they are affected. It still asks every partner to watch for unusual sign-ins, new administrator accounts and unexpected remote-access software.

The clients exposed are those whose endpoints those panels manage. A technician who opens a session to an infected host may also be exposed.

What to do

Do not investigate infected hosts through ScreenConnect. Use EDR live response, WinRM or another separate tool. Treat any technician workstation that connected to a suspect host as possibly exposed.
Confirm the five extensions are disabled and do not re-enable them until ConnectWise says so. If RMM+ stays installed anywhere, make sure RMMPlus.AccessKey is set.
Review Run Command and Toolbox history and the instance audit logs for mass runs nobody on your team started.
Look for a second ScreenConnect client on managed endpoints, and for client services you do not recognize.
Isolate affected hosts until cleanup is finished. Huntress saw reinfection after isolation was lifted too early.
Revoke access: end active ScreenConnect web sessions, rotate ScreenConnect credentials, and revoke browser and identity-provider sessions. Enforce MFA. Disabling extensions and resetting passwords does not remove access already planted on endpoints.
Preserve logs before you clean up.

Indicators

These come from Huntress and cover the activity seen so far. Huntress warns that file hashes are weak indicators here, because the scripts are rebuilt for each host. Its full list includes SHA256 hashes for every toolkit file.

Indicator	Type
`185.99.255[.]28`	Attacker ScreenConnect server
`newnewnew.gotdns[.]org`	Attacker relay
`soxnewwork.homedns[.]org`	Attacker relay
`sc.payproofkit[.]com` (`155.94.150[.]39`)	Attacker ScreenConnect panel
`cdn007-digitaldownloads[.]com`	Command and control domain
`ns.mo7sen[.]dev`	Stager host
`2588ef5c15954b10`	Rogue client ID
`ed630cc2c873b091`	Rogue client ID
`Addmin`	Attacker participant name
`&c=Exploited<N>` in `/Bin/ScreenConnect.ClientSetup.msi` requests	Installer pattern
`C:\Windows\TEMP\sc.msi`	Rogue client installer
`C:\ProgramData\RelayTrap\`	Persistence folder
`TrapWatch`	Scheduled task
`RelayTrapLiteAlert` under `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run`	Run key value
`Panel-Lateral.ps1`, `runnew.cmd`, `ToolboxRelayUploader.exe`, `Run-Lateral-Full.bat`	Toolkit files

Also today

Update: new N-central exploits work against the HF2 build. The November 11 briefing covered N-central 2026.4 Hotfix 2, build 2026.4.1.26. The same researcher has now published two more exploit chains with proof-of-concept code that works against that build, as reported by The Hacker News. One claims unauthenticated root code execution on the server. The other claims SYSTEM command execution on managed Windows agents if the attacker knows the appliance ID. According to the same report, N-able says the server issue needs the Legacy API, which is off by default, to be turned on and exposed to the internet. Hosted servers are not affected. Probing of on-premises servers started within hours, with no confirmed compromise so far. N-able's own update says it is seeing scanning tied to the public code and that a follow-up hotfix is coming, with no date. Keep HF2 installed, turn the Legacy API off, and keep the server off the open internet.

Apache HTTP Server 2.4.71 fixes a critical HTTP/2 flaw. CVE-2026-119618 is heap corruption in mod_http2 that Apache says can lead to remote code execution. It affects 2.4.55 through 2.4.70 and the standalone mod_h2 2.0.8 through 2.0.42. Apache released 2.4.71 on November 11. Only servers with HTTP/2 turned on are affected. No exploitation in the wild has been reported. Red Hat scores it 9.8 but rates it Important on RHEL 9 and 10, and says RHEL 8 and earlier are not affected. Debian's tracker listed a fix only for unstable when this was written. Update where your distribution has a fix. Elsewhere, remove h2 and h2c from the Protocols directive until it does.

Zoom Workplace for Windows fixes a 9.6 flaw. ZSB-26023, published November 10, covers CVE-2026-108186. It lets an unauthenticated attacker escalate privileges over the network, with some user interaction. It affects versions 7.1.0 up to, but not including, 7.1.8. Zoom does not report exploitation. Push the current Zoom Workplace build to managed Windows devices.