SCKit uses ScreenConnect access to spread remote-control malware
Threat actors are abusing cloud-hosted ConnectWise ScreenConnect instances used by managed service providers (MSPs) to install unauthorized remote-access clients and deploy SCKit, a malicious toolkit, on customer endpoints. Microsoft Threat Intelligence said it confirmed activity ConnectWise reported beginning November 11, 2026. The campaign can put both managed devices and IT support technicians at risk.
SCKit is designed to establish access that operates separately from an MSP’s legitimate ScreenConnect environment. Its components also target technicians who connect to an affected customer device, creating a potential path to additional endpoints. Organizations should therefore investigate technician workstations as well as customer systems, rather than treating an unexpected client as an isolated installation.
Separate routes into servers and technician devices
ScreenConnect, formerly ConnectWise Control, lets technicians administer customer devices through a management instance, technician workstations and endpoint clients. Microsoft described two distinct attack surfaces in this activity. One concerns server-side access and the use of ScreenConnect to issue commands; the other is SCKit’s attempt to reach a technician through a compromised customer endpoint.
ConnectWise has described a reported authentication flaw affecting RMM+ extension versions 1.0.31 and 1.0.32. When no access key was configured, the extension accepted an empty key, potentially allowing unauthenticated command submissions to its API. ConnectWise is investigating extension abuse as a possible initial-access route, but the entry method for the reported campaign remains under investigation. This reported server-side route should not be conflated with RelayTrap, SCKit’s component for targeting a technician’s client.
After commands are issued through ScreenConnect, SCKit can install an additional client that connects to infrastructure controlled by the threat actor. The toolkit then stages scripts and components, establishes persistence using a scheduled task and a registry Run entry, and prepares RelayTrap. That component is designed to deliver a launcher to a technician workstation when a technician connects to the compromised endpoint using a vulnerable host client.
SCKit also seeks access to technicians’ browser-based ScreenConnect sessions. Its capabilities include searching Chrome, Edge, Opera and Opera GX profiles for authentication cookies, as well as examining browser process memory. A separate distribution component is designed to use console access to enumerate available sessions and distribute payloads through the management environment. The reach of that activity depends on the account’s permissions.
Why removing an extra client is not enough
The unauthorized client provides a remote-access channel independent of the MSP’s approved ScreenConnect instance. Removing it alone does not eliminate SCKit’s persistence or invalidate browser sessions that may have been exposed. The toolkit’s cleanup component can remove artifacts and restore services, but its behavior also includes an option to restart deployment. Microsoft advises against using a cleanup script recovered from the kit as a remediation tool.
ConnectWise says ScreenConnect client version 26.6.5 and later blocks the toolkit’s attempted endpoint-to-technician transfer technique. The related fix for CVE-2026-84869 was released on September 8, 2026. Organizations should verify the versions installed on technician workstations: updating a cloud console does not automatically update those clients. ConnectWise’s vendor bulletin also describes temporary file-transfer restrictions while updates are pending.
Investigation and response priorities
Scope the investigation across affected customer endpoints, technician workstations and the management environment. Use Microsoft Defender for Endpoint live response or another approved out-of-band method on suspected devices rather than relying on the ScreenConnect session under investigation. Isolate affected systems as appropriate and preserve evidence before remediation.
Correlate ScreenConnect extension, authentication, Run Command and Toolbox records with endpoint process, file, task, registry and network history. Review Toolbox activity for tools that were uploaded and subsequently removed, and inspect queued commands and tools before reconnecting devices. Check whether an endpoint has an unapproved client, unexpected relay destination, unfamiliar persistence entry or antivirus exclusion. Validate any client against the organization’s authorized instance inventory before removing it.
From a clean device, invalidate affected ScreenConnect web sessions and associated identity-provider sessions, rotate exposed credentials, and review account permissions. Password changes alone may not terminate active sessions. Remove unauthorized clients and persistence through approved response tooling, then verify that tasks, scripts or services have not been recreated. If device integrity cannot be established, rebuilding may be necessary.
Use endpoint telemetry to build the timeline
Microsoft recommends reviewing related Defender XDR alerts alongside device timelines and ScreenConnect audit records. The activity spans command execution, persistence, remote-management software installation and browser data access, so individual alerts should be assessed in context. Correlating these signals can help analysts identify the original affected endpoint, determine whether a technician workstation was targeted, and assess the scope of any management-console distribution.
Organizations should keep Microsoft Defender Antivirus, cloud-delivered protection and tamper protection enabled, and verify that devices meet the requirements for protecting antivirus exclusions. Application control and an inventory of approved remote-management instances can also help identify unapproved clients. Because server-side extension authentication and technician-client transfer are separate issues, defenders should address both rather than assuming a single update or cleanup action removes every access path.
