What happened
At approximately 17:48 UTC on 11 November 2026, Huntress observed ScreenConnect instances issuing Run Command instructions that installed a second attacker-controlled ScreenConnect client on reachable hosts. The same activity retrieved a PowerShell toolkit, created SYSTEM-level persistence and attempted to turn a technician connection into a route back into the technician’s own ScreenConnect environment. By the initial public reporting, Huntress was tracking six compromised MSPs, 286 affected endpoints and 47 organisations; ConnectWise separately identified about 400 partner environments with at least one listed extension, but said extension presence alone did not establish compromise.
ConnectWise published its initial advisory at 22:45 UTC on 11 November 2026 and described cause and scope as under investigation. ConnectWise’s five precautionary extension names are Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. Cloud-hosted instances were disabled where ConnectWise could act; on-premises partners had to disable them themselves. ConnectWise warned that disabling extensions and resetting credentials would not remove unauthorised software, persistence or access already established on endpoints.
The published investigation indicators were 185.99.255[.]28, 155.94.150[.]39, newnewnew[.]gotdns[.]org, soxnewwork[.]homedns[.]org, sc[.]payproofkit[.]com and ns[.]mo7sen[.]dev. The published host and ScreenConnect artefacts included C:\ProgramData\RelayTrap, C:\ProgramData\RelayTrap\TrapWatch.ps1, %TEMP%\sckit-*, the TrapWatch scheduled task, RelayTrapLiteAlert, client IDs 2588ef5c15954b10 and ed630cc2c873b091, and files sckit-run.bat, sckit-decoder.ps1, TrapWatch.ps1, Panel-Lateral.ps1, Run-Lateral-Full.bat, runnew.cmd and ToolboxRelayUploader.exe. The cited sources did not publish cryptographic hashes for the ScreenConnect toolkit. Attribution posture: ConnectWise has not named an actor, and the initial access method and full scope remained unresolved at publication.
Why this matters now
This is not a single-customer remote-access alert. ScreenConnect sits above many downstream organisations, so one partner account can become a distribution point into customer endpoints while infected endpoints may, in turn, endanger the technician who investigates them. That bidirectional path invalidates the normal assumption that the management console and technician workstation are trusted recovery tools.
The approximately 400 environments are an exposure cohort, not a victim count. Leaders should resist both underreaction and overstatement: extension presence is enough to trigger containment and evidence preservation, but compromise must be proved per partner and per managed customer. The immediate risk is the privileged reach of the control plane, not the extension name alone.
Routine password resets, MFA enforcement and software currency remain necessary, but they do not close an incident where a second remote-access client, scheduled task or captured technician session may persist. The enterprise dependency on MSP access means customer security teams need evidence from the provider, not a generic assurance that the extension was disabled.
The decision for security leaders
The MSP security lead should freeze interactive ScreenConnect sessions to suspected hosts, isolate affected systems with separate tooling and preserve authentication, extension, administrative, Run Command and Toolbox records before cleanup. A trusted device should then be used to revoke ScreenConnect and identity-provider sessions and reset credentials.
Enterprise third-party risk owners should require tenant-specific scope: which technician identities connected, which customer endpoints received Run Command activity, which extensions were installed, and what evidence shows no rogue remote-access client or persistence remains. Blanket platform-wide statements are insufficient because ConnectWise says it lacks telemetry inside partner environments after initial access.
Reconnection should be an explicit incident decision, jointly owned by the MSP, customer incident commander and service owner. Approval should depend on endpoint and technician-workstation validation, not merely extension removal. If a critical support service cannot remain paused, document the exception, restrict reach and time-box the alternative access path.
Evidence of closure
- Extension inventory shows none of the five listed extensions enabled.
- Run Command and Toolbox review records an approved disposition for every anomaly.
- Endpoint and technician-workstation scans show no listed indicators or unauthorised remote clients.
- Session-revocation records cover every affected administrative identity and identity provider session pathway with evidence of successful invalidation and no residual active session tokens remaining in the control plane or connected technician estate after containment is declared complete, documented and independently.
The Security.io assessment
Security.io assesses the campaign as a control-plane incident with credible downstream propagation, supported by vendor confirmation and Huntress telemetry. The evidence is strong that unauthorised remote-access software reached customer environments; the evidence is not yet sufficient to state one universal initial-access mechanism or that every environment carrying the five extensions was compromised.
The most important uncertainty is technician-workstation compromise. Huntress described a toolkit designed to capture a connecting technician session, while ConnectWise said those reports remained subject to validation. Until each potentially exposed technician device is checked, using the same support channel for investigation risks extending the incident.
Closure therefore requires two independent proofs: the ScreenConnect control plane no longer contains unauthorised identities, extensions or command activity, and the endpoint estate no longer contains the published network, filesystem, persistence or rogue-client indicators. Absence of those indicators reduces risk but does not rule out variants, so behavioural review and preserved evidence remain necessary.
Questions for the morning meeting
- Which customer environments can one MSP technician identity reach?
- Can the provider be suspended without losing critical support coverage?
- Who owns notification to downstream customers and regulators?
- What evidence will the provider deliver for each managed tenant?