"The attacks compromised at least 288 endpoints across 48 organizations, with all of the affected devices targeted within 90 minutes." Those numbers, reported by Huntress, capture both the speed and scale of a recent campaign that weaponized a new toolkit called SCKit against managed service providers (MSPs) using ScreenConnect.
SCKit and RelayTrap: a toolkit built to turn support sessions against technicians
Researchers at Huntress and Blackpoint Cyber describe SCKit as a collection of 16 scripts and components assembled to establish persistent remote access and to spread between systems managed through ScreenConnect. Central to the toolkit is RelayTrap, a component designed to replace the legitimate ScreenConnect Guest process on an infected endpoint and wait for an MSP technician to connect.
Rather than delivering RelayTrap as a compiled binary, attackers stored a C# source file named RelayTrap.cs on their infrastructure. A PowerShell script on compromised devices compiled that source locally into an executable. A separate component called TrapWatch monitors ScreenConnect services and prepares the replacement Guest process to intercept incoming support sessions.
When a technician connects, RelayTrap attempts to reverse the usual file-transfer direction of remote support: instead of the technician sending a file to the customer endpoint, the malicious Guest tries to send a file back to the technician’s workstation. If successful, further SCKit modules would then attempt to steal ScreenConnect authentication cookies from web browsers and use the technician’s session to enumerate endpoints and issue commands through legitimate management features such as the Shared Toolbox.
CVE-2026-84869: the attempted exploit and the role of a patched client
The mechanism SCKit tries to exploit is CVE-2026-84869, described in the reporting as a critical ScreenConnect client-side file-transfer vulnerability that ConnectWise patched in version 26.6.5. Under the vulnerability’s logic, a malicious Guest process could send a file to a technician and have it executed on the technician’s workstation.
Both Huntress and Blackpoint reported they have not observed the worm-like exploit succeed in the current campaign. Blackpoint’s Adversary Pursuit Group recovered the loader from attacker infrastructure, decrypted subsequent stages, and tested the toolkit against a current ScreenConnect client. As Blackpoint researchers Sam Decker and Nevan Beal told BleepingComputer: "The Guest side queued the transfer, but the current client never requested or ran the payload."
Huntress likewise reported console takeover attempts failed in every recovered host log it examined. Those findings indicate the existing ConnectWise client fix prevented the RelayTrap payload from executing on tested systems.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageRMM+ authentication flaw: how attackers likely gained initial access
Huntress believes the attackers achieved initial access via RMM+, a third‑party ScreenConnect extension intended to let external management tools interact with ScreenConnect sessions without using the standard technician console. Huntress found that RMM+ versions 1.0.31 and 1.0.32 contained an authentication flaw.
RMM+ uses a shared access key to authenticate requests rather than ScreenConnect’s normal user accounts and authentication mechanisms. In the vulnerable RMM+ versions, if an administrator had never configured an access key, the extension allowed that key to remain blank. An attacker could then supply an empty access key and pass the extension’s authentication check, allowing them to issue remote commands through the ScreenConnect environment without authenticating to ScreenConnect or completing multifactor authentication.
Huntress says this behavior matches activity observed during the attacks: commands executed across multiple ScreenConnect instances without corresponding user login activity, and logs linked those commands to RMM+.
ConnectWise response, observed impact, and the recovered artifacts
As part of its response, ConnectWise disabled five potentially related third‑party extensions across approximately 400 partner environments, while stressing that the presence of those extensions does not mean those environments were compromised. Blackpoint recovered the attackers’ loader and the ScreenConnect installer used in the campaign from attacker-controlled infrastructure and decrypted later stages to obtain the complete loader.
Huntress’s updated reporting quantified the intrusion: at least 288 endpoints across 48 organizations were targeted, with about one‑third of affected systems targeted within the first 10 minutes and all within 90 minutes. Both research teams reported they have not observed SCKit’s intended worm-like behavior successfully propagate in the campaign so far.
What this means for MSPs, security teams, and customer organisations
- MSPs: Review and, where necessary, disable third‑party ScreenConnect extensions — Huntress specifically urged disabling affected extensions — and investigate any unauthorized remote‑access installations. Confirm ScreenConnect clients are updated to at least the patched version referenced by ConnectWise.
- Security teams: Examine Run Command and Shared Toolbox activity for anomalous commands and review logs for actions that lack corresponding technician login activity; avoid interactive ScreenConnect sessions with potentially infected endpoints and use separate security tools for investigation, as recommended by the researchers.
- Customer organisations: If you rely on MSPs that use ScreenConnect, ask whether RMM+ or other third‑party extensions are in use and ensure MSP partners have applied the ConnectWise client patch (26.6.5) and checked extension configuration for blank access keys.
The campaign exposed a clear pattern: a fast-moving, automated attempt to weaponize a remote-support workflow against the very technicians trusted to fix problems. For now, both Huntress and Blackpoint’s testing points to effective protection where ScreenConnect clients are patched; where RMM+ remains unconfigured or third‑party extensions are enabled, the attack chain still has plausible footholds. The next weeks will show whether defenders keep pace with patching and configuration hardening, or whether attackers refine SCKit to evade current mitigations.
