The Challenge
On November 11, 2026, ConnectWise reported a campaign where a threat actor accessed cloud-hosted ScreenConnect instances of managed service providers (MSPs). Microsoft Threat Intelligence confirmed this activity, noting the misuse of ScreenConnect to install unauthorized remote-access clients and deploy a worm called SCKit on customer-managed endpoints.
The core issue for defenders is that the attacker's initial actions resemble standard administration. Commands issued through an MSP's management console, executed by a trusted client, are difficult to distinguish from routine technician work. This case study examines the technical facts to identify decisions your security team can make now.
Environment and Constraints
ScreenConnect consists of three components: a management instance (cloud-hosted or on-premises) providing the web console and relay service, technician workstations accessing through a browser, and customer endpoints running an installed access client. This structure creates two distinct attack surfaces.
The first is server-side. Extensions add features and integrations, including ticketing and RMM tools. The RMM+ extension family exposes remote-command APIs protected by a separately configured passphrase rather than the technician's normal console sign-in. ConnectWise's advisory describes an authentication flaw in RMM+ versions 1.0.31 and 1.0.32: when no access key was configured, the extension accepted an empty key. An unauthorized caller could submit commands to the server's API for delivery to managed endpoints without a normal sign-in. ConnectWise is investigating extension abuse as an initial-access route, and the entry method for the reported campaign remains under investigation.
The second is client-side. SCKit includes RelayTrap, a malicious replacement for the ScreenConnect client on an affected customer endpoint, designed to deliver a payload to a technician's workstation when they connect for support. ConnectWise states that the fix for CVE-2026-84869 blocks this attempted endpoint-to-technician spread.
The critical constraint: extension authentication is separate from user authentication. Your MFA and conditional access policies on technician logins don't protect an API that accepts an empty key.
The Attacker's Chain
Understanding the attacker's chain reveals detection and prevention opportunities.
Stage 1: A Second Client. The actor uses the MSP's management instance to direct an installed endpoint client to start cmd.exe, which calls curl.exe to download an MSI over HTTP from an attacker-controlled ScreenConnect server, saved as C:\Windows\Temp\sc.msi. Windows Installer then installs it silently. The new client connects to the attacker's instance, creating a separate channel from the MSP's approved one.
Stage 2: Staging. A batch launcher retrieves a PowerShell decoder. The decoder reads the device's MachineGuid, derives a key using SHA-256, XOR, and PBKDF2-HMAC-SHA256, then decrypts with AES-256-CBC, decompresses with GZip, and extracts the bundle to %TEMP%\SCKitBundle. The key material is device-specific, complicating analysis and detection.
Stage 3: Persistence. Scripts are placed under C:\ProgramData\RelayTrap. A RelayTrapLiteAlert value in the machine-wide Run key launches an alert script at logon. A scheduled task starts a watcher that polls every 10 seconds, enumerates ScreenConnect client services, and compiles RelayTrap.exe using libraries from each legitimate client's installation. ScreenConnect services are set to automatic startup, and registry writes add Microsoft Defender Antivirus path exclusions for staged MSI copies and CWInstall_…\Installer.ps1.
Stage 4: Targeting Technicians. RelayTrap reuses the endpoint's ScreenConnect connection details. When a technician connects with a vulnerable host client, it attempts to deliver the staged launcher through that session, extending the toolkit from customer device to technician workstation. The worm then uses the victim's management console to distribute payloads to other managed devices.
Results and Metrics
The source reporting doesn't provide counts of affected MSPs, endpoints, or dwell times. However, the structural outcomes are clear:
- Actors gained the ability to remotely administer affected endpoints, run commands, and deploy further tools independently of the legitimate support instance.
- Removing an unauthorized client alone does not remove the toolkit's persistence or invalidate exposed web sessions.
- The campaign's entry method remains under investigation, so you can't yet assume a single patch closes it.
This second point should be included in your incident response runbook. Remediation that stops at uninstalling the rogue client leaves scheduled tasks, Run key entries, and live sessions intact.
What They Would Do Differently
A post-incident review suggests several decisions that could have reduced exposure:
- Treat Extensions as Software Supply Chain. An RMM+ build that accepted an empty key was a configuration-dependent flaw. A pre-deployment check ensuring every extension credential is set, non-empty, and rotated would have closed the specific condition described.
- Monitor the Endpoint, Not Only the Console. Malicious activity occurred on customer endpoints and technician workstations. Console audit logs alone wouldn't show curl.exe pulling an MSI into C:\Windows\Temp.
- Inventory Approved Clients. A second ScreenConnect client pointing at an unapproved relay host is detectable if you know which relay hosts are legitimate.
- Protect Defender Configuration. Unexpected path exclusions are a high-signal indicator.
Takeaways for Your Team
Secure the Extension Layer. Inventory every installed extension and its version. For RMM+, confirm you are not running 1.0.31 or 1.0.32, and verify an access key is configured. Align this with the supplier and software controls in ISO/IEC 27002 and the supply chain risk management expectations in NIST Cybersecurity Framework (CSF) 2.0.
Enforce the Principle of Least Privilege on Console Actions. Limit who can issue remote commands, and limit which devices a given console identity can reach. A hijacked technician session should not reach every managed endpoint.
Hunt for Persistence, Not Just the Client. Search for the RelayTrapLiteAlert Run value, scheduled tasks launching a watcher with a 10-second poll, C:\ProgramData\RelayTrap, unexpected Defender exclusions, and temporary k<32-hex>.ps1 files. Microsoft has published Defender XDR advanced hunting queries and indicators of compromise for this activity.
Invalidate Sessions After Cleanup. Because exposed web sessions survive client removal, rotate credentials and terminate active console sessions on every affected technician workstation and downstream endpoint.
Tighten Containment, Eradication, and Recovery Scope. Include technician workstations and downstream managed devices, not just the endpoint where the rogue client was found.
Consider Just-in-Time Access for Technician Sessions. Persistent, unattended access is the feature the attacker abused. Reducing standing access shrinks what a compromised console can reach.
The lesson isn't that ScreenConnect is uniquely flawed. Any remote-support platform with an extension ecosystem and unattended access carries similar risks. Audit it like the privileged infrastructure it is.
