ScreenConnect Rogue Clients: Evict SCKit From MSP Networks

ScreenConnect rogue clients can keep an attacker inside customer systems after an MSP resets passwords, disables a suspect extension, or secures the original management console. Huntress published fresh incident guidance on November 12, 2026, after observing an attacker use ScreenConnect's Run Command function to install a second, attacker-controlled client and the SCKit toolkit across managed endpoints.

The campaign reached at least 288 endpoints across 48 organizations, according to current reporting. More importantly, the toolkit is designed to turn a technician connection into another route for expansion. If you manage ScreenConnect, the safe response is not a normal remote cleanup. You need to isolate first, investigate from a separate trusted tool, and prove both endpoints and technician workstations are clean before reconnecting them.

Key Takeaway: Do not open an interactive ScreenConnect session to a suspected infected device. The technician workstation may become part of the attack path.

What the ScreenConnect rogue client campaign changes

Huntress published its incident guidance on November 12, reporting malicious activity delivered through compromised ScreenConnect environments. At approximately 17:48 UTC on November 11, affected instances issued commands that downloaded and silently installed a second ScreenConnect client tied to attacker infrastructure.

The same command retrieved a PowerShell-based toolkit, created a scheduled task running as SYSTEM, and placed a modified client that could impersonate the legitimate client. Huntress calls the toolkit SCKit, while its relay and persistence components use names such as RelayTrap and TrapWatch.

This is different from a simple stolen admin session. A password reset can close the account the attacker used, but it does not uninstall the second client already planted on customer devices. Disabling a third-party extension can remove one control path, but it does not erase scheduled tasks, altered clients, staged scripts, or credentials already taken from endpoints.

ConnectWise says its investigation remains ongoing. The company reports no evidence that its infrastructure was compromised or that a vulnerability in ScreenConnect itself caused the activity. Its current assessment points to possible abuse of independently developed third-party extensions, but the initial access method and full scope are still being validated.

That uncertainty matters. Do not turn a developing hypothesis into a confident root-cause statement. Base containment on the observed behavior, then preserve the logs needed to test the extension, account, session, and endpoint theories later.

Common Mistake: Treating an extension disablement or password reset as eradication. Those steps can stop one route while the rogue endpoint client continues reporting elsewhere.

How SCKit creates persistence and a technician trap

The observed intrusion uses ScreenConnect's legitimate administrative reach to deploy an illegitimate control channel. On an affected host, the attacker can install another ScreenConnect client, stage scripts in Windows temporary directories, and create SYSTEM-level persistence.

The most important observed artifacts include:

• a scheduled task named TrapWatch, reportedly running every 10 seconds
• the directory C:\ProgramData\RelayTrap\
• staging paths matching C:\Windows\Temp\sckit-*
• rogue ScreenConnect client IDs 2588ef5c15954b10 and ed630cc2c873b091
• tools and scripts including sckit-run.bat, sckit-decoder.ps1, Panel-Lateral.ps1, and ToolboxRelayUploader.exe

Sophos observed the malicious deployment chain using curl.exe to download a ScreenConnect installer, followed by msiexec.exe for silent installation. Researchers also saw ScreenConnect-generated scripts use PowerShell with execution-policy bypass to retrieve a second stage.

The relay trap creates the more unusual risk. Huntress found code designed to wait for a technician to connect to an infected endpoint, then deliver the toolkit to that technician's workstation. Other components attempt to obtain browser-stored session material and use the technician's access to reach additional panels and endpoints.

Some of that lateral functionality has been reconstructed from the malware rather than observed succeeding in every incident. Keep that distinction clear. The safe response still treats technician workstations as potentially exposed because the consequence of connecting from a privileged support device is high.

Key Stat: Huntress observed 288 managed endpoints in 48 organizations, while ConnectWise identified about 400 partner environments with at least one extension from the investigated RMM+ family installed. Extension presence alone does not prove compromise.

Contain ScreenConnect rogue clients in the right order

Sequence matters because familiar support actions can create new exposure. Start with network containment and an out-of-band command channel rather than logging into suspect devices through the same management plane.

1. Stop interactive ScreenConnect access

Tell technicians not to connect to suspected endpoints from any ScreenConnect instance, including a newly created or trial instance. Suspend automated jobs that could unintentionally invoke shared tools or broadcast commands while you establish scope.

Use EDR isolation, local console access, a separately managed response agent, or another trusted channel. If none is available, keep the device disconnected until you can investigate it safely.

2. Secure the management plane from a trusted device

From a workstation that has not connected to affected hosts, revoke active ScreenConnect and identity-provider sessions. Reset relevant passwords, enforce phishing-resistant MFA where supported, remove unknown users, and review administrative role changes.

Verify that the five extensions named by ConnectWise are disabled: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, and RMM+ Password Link. On-premises partners must perform this action themselves. Preserve extension configuration and installation records before removal when doing so will not prolong active access.

The earlier Hexon guide to session revocation after a password reset explains why changing a password and invalidating live sessions are separate actions. In this campaign, you must also account for access established outside the original panel.

3. Isolate endpoints and technician workstations

Isolate every endpoint with confirmed indicators. Also identify technicians who connected to those systems during the exposure window and isolate their workstations until checked.

Prioritize domain controllers, backup servers, hypervisors, identity systems, and devices holding privileged browser sessions. If one of those assets received the attacker command, plan for a domain-level or infrastructure-level credential review rather than a single-host cleanup.

Pro Tip: Build two scope lists, not one. The first contains endpoints reached by the malicious command. The second contains technician workstations that later connected to those endpoints.

Hunt for evidence beyond published indicators

Indicators are a starting point, not a clean bill of health. Domains, IP addresses, filenames, and client IDs can change quickly. Hunt for the behavior that connects the panel, installer, PowerShell stage, persistence, and outbound control channel.

Review these ScreenConnect records:

• Run Command history for mass or unexpected execution
• Toolbox changes, uploads, and rapid deletion
• authentication events from unusual locations or devices
• new users, role changes, and permission changes
• extension installations and API access configuration
• session activity involving affected endpoints and technicians

On Windows endpoints, correlate ScreenConnect processes with curl.exe, PowerShell, msiexec.exe, scheduled-task creation, Defender exclusion changes, and new ScreenConnect services or installation directories. Compare every affected host with a known-good endpoint under the same customer and policy.

Do not search only for the published paths. Look for a second remote-management service, an unexpected client certificate or fingerprint, recently created SYSTEM tasks, renamed PowerShell payloads, and outbound traffic that begins immediately after a management command.

The endpoint hygiene checklist can support the inventory and logging baseline, but incident scoping must be more precise. You need timestamps, parent processes, operator identity, affected customer, and the first known command for each system.

Remove SCKit without destroying the evidence

Preserve volatile and high-value evidence before deleting artifacts. Export ScreenConnect audit records, authentication events, extension details, command history, Toolbox activity, EDR telemetry, scheduled tasks, running processes, network connections, and relevant browser-session evidence.

Then remove the malicious persistence and client using your response provider's validated procedure. A complete eradication step should address:

1. attacker-controlled ScreenConnect clients and services
2. RelayTrap and SCKit files, tasks, run keys, and staging directories
3. altered or impersonated legitimate ScreenConnect components
4. Defender exclusions and other security-control changes
5. additional remote-access tools or accounts created during the intrusion

Reinstalling the legitimate ScreenConnect client can be appropriate after eradication, but only from a known-good source and only after the management plane is secured. Reboot when the response procedure requires it, then verify that the malicious task, service, process, and outbound traffic do not return.

If evidence suggests credential theft, assume the endpoint cleanup did not revoke what the attacker already copied. Rotate domain administrator, service, backup, hypervisor, API, and browser-stored credentials in an order that prevents old privileges from re-establishing access.

Hexon's vendor access risk checklist is useful for the longer-term access review. During an active incident, however, focus first on identities that can cross customer boundaries or control backup, identity, and security infrastructure.

Key Takeaway: Eradication removes malicious software. Credential rotation and session revocation remove the access that software may already have produced.

Prove recovery before reconnecting customers

Recovery should require evidence from three layers: the ScreenConnect environment, technician workstations, and managed endpoints. A clean result in one layer cannot compensate for an untested layer elsewhere.

For the management plane, confirm that suspect extensions remain disabled, active sessions have been revoked, administrative access is known, MFA is enforced, and logs show no unexplained commands after containment. Review extension API configuration and remove administrative access that is not operationally necessary.

For technician workstations, verify that no relay components, rogue clients, stolen session artifacts, unexpected browser extensions, or new persistence remain. Use a trusted workstation for the final panel review rather than a device that participated in the incident.

For customer endpoints, verify removal across the full inventory, not a sample chosen for convenience. Confirm that expected client IDs, services, tasks, installation paths, security settings, and network destinations match the approved baseline.

Reconnect in small groups and watch for recurrence. If a newly restored host causes the malicious task, second client, or outbound traffic to reappear, isolate the group and reopen the incident. The N-able N-central response guide covers the broader reason for this caution: an RMM platform concentrates trust, so a missed control-plane problem can scale across customers quickly.

Define a written exit criterion. For example: all known endpoints reviewed, all affected technician devices rebuilt or cleared, all privileged credentials rotated, all sessions revoked, no malicious activity for a monitored period, and an independent reviewer approving reconnection.

Hardening MSP remote access after the incident

The campaign is still developing, so hardening should not depend on one final root-cause theory. Reduce the paths that let any compromised account, session, or extension issue broad commands across customers.

Start with these controls:

• require phishing-resistant MFA for privileged users where available
• separate technician accounts from everyday email and browsing identities
• limit global commands and Toolbox access to a small, monitored role
• review third-party extensions as privileged code with owners and renewal dates
• alert on mass Run Command use, new clients, extension changes, and second RMM agents
• isolate customer groups so one operator context cannot reach every tenant by default
• use privileged workstations for management-plane access
• retain logs long enough to reconstruct activity across panel, technician, and endpoint layers

Run a tabletop exercise around a compromised technician workstation. Ask how the team would communicate without the normal RMM channel, how it would isolate hundreds of customer endpoints, and which credentials must rotate first.

Finally, make customer communication part of the playbook. Customers need a clear statement of what is confirmed, what remains under investigation, which devices were isolated, and what actions they must avoid. Do not imply that extension presence alone proves compromise, and do not imply that a password reset alone proves safety.

ScreenConnect rogue clients turn a trusted support workflow into a persistence and propagation problem. The practical defense is disciplined separation: investigate through another channel, protect the technician, remove the second control path, rotate exposed authority, and reconnect only when evidence supports it.