What happened
At approximately 17:47 UTC on November 11, 2026, Huntress observed suspicious activity across multiple cloud-hosted ScreenConnect environments. Huntress counted at least 288 hosts across 48 organisations affected over 90 minutes, with about one third affected in the first 10 minutes. Operators used ScreenConnect’s Run Command capability to install attacker-controlled remote-access clients and the SCKit toolkit across managed endpoints.
ConnectWise published its initial advisory at 22:45 UTC on November 11, 2026 and updated its assessment at 18:45 UTC on November 12, 2026. ConnectWise identified approximately 400 partner environments with at least one RMM+ family extension installed; that number is not a confirmed compromise count. The five extensions named for precautionary disabling are Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link.
Huntress reported that RMM+ versions 1.0.31 and 1.0.32 could accept a blank access key, but ConnectWise has not confirmed that mechanism as initial access. SCKit is a 16-file toolkit containing PowerShell, batch, command and configuration files designed to establish access and attempt propagation through ScreenConnect sessions. The attempted endpoint-to-technician spread uses CVE-2026-84869 and is blocked by ScreenConnect client 26.6.5; Huntress and Blackpoint did not observe successful exploitation during this campaign.
Published host indicators include Run-Lateral-Full.bat, runnew.cmd, ToolboxRelayUploader.exe, C:\ProgramData\RelayTrap, C:\ProgramData\RelayTrap\TrapWatch.ps1, %TEMP%\sckit-*, scheduled task TrapWatch, registry value RelayTrapLiteAlert, fingerprints 2588ef5c15954b10 and ed630cc2c873b091, and account names Addmin and rmmserver. Attribution posture: No actor attribution has been established for the November ScreenConnect activity. The cited sources did not establish the initial access method or full scope of the ScreenConnect activity. The cited source did not publish the specific operational detail described as Initial access and complete scope remain unresolved.
Why this matters now
ScreenConnect occupies a privileged position between MSP technicians and many customer endpoints. The observed campaign used legitimate remote-management functions to deploy additional access, so a single compromised partner environment can create incident-scoping obligations across multiple customers without exploiting each customer’s perimeter separately.
Disabling the extensions is necessary but is not evidence that access, persistence or rogue clients were removed. The attacker reportedly deployed additional ScreenConnect clients and SCKit components to endpoints. Technician workstations that connected to those endpoints belong inside the investigation because the toolkit attempted to reverse the normal direction of trust in a support session.
The distinction between approximately 400 extension-bearing environments and confirmed compromise is important. Overstating that number would create inaccurate victim claims; understating the risk would ignore the command-execution capability and observed endpoint impact. Security leaders need partner-specific evidence rather than relying on the vendor’s aggregate precautionary action.
The decision for security leaders
Separate extension exposure from confirmed compromise, but do not use that distinction to delay investigation. Every partner with a named extension needs an evidence-backed review of administrative access, command execution, Toolbox activity, rogue client deployment and technician sessions. Customer organisations should request scoped findings rather than a generic vendor reassurance.
Place the MSP control plane under joint incident ownership. The MSP should lead evidence collection across its console and technician fleet; each customer should validate endpoint and identity impact inside its own boundary. Avoid interactive support sessions to suspect devices because the recovered toolkit was designed to exploit the trust relationship with the connecting technician.
Closure requires removal of established access, not only disabling the suspected entry mechanism. Validate ScreenConnect client versions, unauthorised accounts, scheduled tasks, registry persistence, remote-access software and session credentials before restoring ordinary support operations.
Evidence of closure
- Extension inventories show all five named extensions disabled or absent in every tenant.
- Run Command and Toolbox records have an approved disposition for every unexpected action.
- Endpoint validation finds no RelayTrap, SCKit, rogue-client or persistence indicators.
- Technician clients and endpoint agents are verified at ScreenConnect 26.6.5 or later.
The Security.io assessment
ConnectWise’s statement that it found no evidence of compromised ConnectWise infrastructure materially narrows the current hypothesis, but it does not clear partner environments. The vendor also lacks complete telemetry inside partners and their customers after initial access, making decentralised evidence collection unavoidable.
The worm-like endpoint-to-technician technique is consequential even though researchers did not observe it succeeding. It establishes a credible reason to include technician workstations in scope and to avoid interactive connections until client version and endpoint condition are verified. The observed incident already involved rogue remote access without that propagation stage succeeding.
Questions for the morning meeting
- Which managed customers were reachable through every affected ScreenConnect partner console?
- Did any technician establish an interactive session with a suspected endpoint?
- Can the MSP prove which Run Command and Toolbox actions were authorised?
- Are customer contracts clear about control-plane incident notification and evidence delivery?