SCKit Turns ScreenConnect Trust Into an MSP Supply-Chain Attack

SCKit Turns ScreenConnect Trust Into an MSP Supply-Chain Attack

An active campaign is abusing the trust built into managed service provider (MSP) remote-management workflows. Huntress says the SCKit toolkit reached at least 288 hosts across 48 organizations through compromised ScreenConnect environments, installing attacker-controlled clients and attempting to turn technician access into a propagation mechanism.

Why this is a supply-chain problem

The incident is not simply a malware infection on isolated endpoints. The attacker reached a management plane used by MSPs, then used that plane's legitimate command and deployment capabilities to affect downstream customers. That is the defining danger of a supply-chain attack: compromise at a trusted provider or tool can become a force multiplier across organizations that did not share the original intrusion.

Huntress observed the activity on November 11, 2026, and reported that 288 hosts at 48 organizations were affected within roughly 90 minutes. ConnectWise said it identified unauthorized access to ScreenConnect partner accounts and deployment of unauthorized remote-access software in customer environments. The company also disabled five third-party extensions as a precaution after identifying them in approximately 400 partner environments.

The numbers are a floor, not a complete incident census. Sequential attacker-assigned tags suggested that other MSP environments may have been targeted before the activity was detected.

How SCKit weaponizes a trusted path

The observed workflow starts with access to a ScreenConnect environment. An unauthorized party used the platform's Run Command capability to download and install a second, attacker-controlled ScreenConnect client on reachable hosts, alongside a toolkit designed to spread.

That choice is operationally effective because remote-management software already has the permissions and network reach defenders expect from an administrator tool. A rogue client can blend into a familiar product name while preserving a path for command execution and persistence. The campaign also attempted to capture a technician's session context so that connecting from an infected host could expose another ScreenConnect instance and its managed endpoints.

This is a reminder that incident response for an MSP cannot stop at the first infected workstation. The investigation has to move upward into the control plane, partner accounts, extensions, technician browsers, and every customer environment reachable from the affected instance.

What defenders should do now

Organizations using ScreenConnect, especially MSPs, should treat this as a management-plane containment event:

• Review ScreenConnect Run Command history, partner-account activity, extension inventory, and newly created or unexpected client sessions from November 11 onward.
• Verify that the five extensions named in ConnectWise's advisory are disabled, and independently confirm that they were not re-enabled or replaced by an equivalent extension.
• From a clean administrative device, terminate active ScreenConnect web sessions, rotate ScreenConnect credentials, and revoke related browser and identity-provider sessions.
• Enumerate every ScreenConnect client installed on managed endpoints. Compare binaries, hashes, configuration, service paths, and connection identifiers against known-good vendor builds.
• Isolate hosts with an unexpected second client or suspicious toolkit before allowing a technician to connect to them through another ScreenConnect instance.
• Assume that credentials and session material visible to a technician on an affected host may be exposed. Rotate privileged credentials and review identity-provider, VPN, cloud, and customer-tenant logs.
• Preserve panel, endpoint, proxy, identity, and EDR telemetry before cleanup. The Run Command timeline is especially important for scoping downstream impact.

Patching the underlying product is useful, but it is not sufficient evidence of containment when the campaign used valid management functionality and third-party extensions. A clean rebuild of the management plane and a customer-by-customer validation may be necessary when account or session compromise cannot be excluded.

The control-plane lesson for MSPs

Remote-management systems are part of the security boundary even when they are marketed as operations tools. Their extensions, automation features, API tokens, browser sessions, and technician endpoints should be governed like privileged identity infrastructure.

Three controls reduce blast radius:

1. Separate administrative access from ordinary technician browsing and require phishing-resistant MFA for high-impact actions.
2. Alert on bulk Run Command activity, new client registrations, extension changes, and management actions that cross customer boundaries.
3. Maintain an out-of-band kill switch: a way to disable remote access, revoke sessions, and quarantine downstream clients without depending on the potentially compromised console.

The last control is often neglected. If the management plane is the incident's propagation channel, asking the same plane to prove that it is clean is circular.

Bottom line

SCKit shows how quickly trust in an MSP tool can become attacker reach across many customers. Review ScreenConnect activity, disable suspicious extensions, rotate access from a clean device, and validate every client—not just the first machine that raised an alert. The strategic fix is to treat remote-management infrastructure as a supply-chain control point with independent containment and detection.

Sources

• Huntress: SCKit Worm Installs Rogue ScreenConnect Clients and Session Cookie Relays
• ConnectWise Trust Center: ScreenConnect Security Advisory
• BleepingComputer: New worm-like SCKit malware targets MSPs

References

1. Huntress: SCKit Worm Installs Rogue ScreenConnect Clients and Session Cookie Relays
2. ConnectWise Trust Center: ScreenConnect Security Advisory
3. BleepingComputer: New worm-like SCKit malware targets MSPs