SCKit targets MSPs through a patched ScreenConnect flaw

By Olivia Hart

Attackers compromised at least 288 endpoints across 48 organizations, targeting every affected device within a 90-minute window; roughly one-third fell in the first 10 minutes. The operation exploited ScreenConnect, the remote-access platform MSPs and IT teams use to manage and troubleshoot customer devices.

Huntress and Blackpoint Cyber separately analyzed SCKit, a collection of 16 scripts and components deployed in the recent attacks to establish persistent remote access and spread among systems managed through ScreenConnect. Neither team has observed its worm-like behavior succeed.

Initial access and the extension flaw

Attackers gained unauthorized access to cloud-hosted ScreenConnect environments and used the platform's Run Command feature to install rogue ScreenConnect remote-access clients on customer endpoints.

Huntress believes initial access came through RMM+, a third-party ScreenConnect extension that lets external management tools interact with sessions without the standard technician console. Versions 1.0.31 and 1.0.32 carried an authentication flaw that could permit command execution without authenticating to ScreenConnect or completing multifactor authentication.

RMM+ normally authenticates requests with a shared access key, not standard ScreenConnect user accounts or authentication mechanisms. The vulnerable releases let that key remain blank when an administrator had never configured one, allowing an attacker to pass the authentication check and issue remote commands.

Observed activity supports that theory: commands ran across multiple ScreenConnect instances without corresponding user logins, and logs linked the commands to RMM+.

Inside SCKit's attack chain

Blackpoint Cyber's Adversary Pursuit Group recovered the malware loader directly from attacker-controlled infrastructure, then decrypted later stages to obtain the complete loader and a ScreenConnect installer used in the attacks. The attackers first deployed additional ScreenConnect Access clients configured to connect to servers they controlled for persistence even if the original MSP session ended.

SCKit is designed to turn a legitimate MSP remote-support session into an attack on the technician who initiated it. Its RelayTrap component replaces the legitimate ScreenConnect Guest process on an infected endpoint and waits for an interactive connection.

Another component, TrapWatch, monitors ScreenConnect services and prepares the replacement Guest process to intercept incoming support sessions. When a technician connects, RelayTrap tries sending a malicious file in the opposite direction of normal support: from the customer endpoint to the technician's workstation.

The attackers stored RelayTrap as C# source code named RelayTrap.cs, not a precompiled executable. Compromised devices download that file, and a PowerShell script compiles it locally into an executable.

The attempt targets CVE-2026-84869, a critical ScreenConnect client-side file-transfer vulnerability that ConnectWise patched in version 26.6.5. ScreenConnect normally lets technicians send files to managed endpoints and execute them remotely. The flaw could potentially let a malicious Guest send a file back to the technician and have it executed.

Recovered source contains extensive comments about functionality, compatibility workarounds and earlier coding errors, giving it the appearance of LLM-generated code. Huntress also believes RelayTrap appears to have been generated using a large language model.

The exploit test

Once running on a technician's workstation, other SCKit components try to steal ScreenConnect authentication cookies from web browsers. Those cookies could let attackers hijack an authenticated management session without the technician's credentials or a new MFA challenge.

The malware then attempts to use the technician's existing ScreenConnect permissions to enumerate accessible endpoints and distribute malicious commands through legitimate management features, including Shared Toolbox. That creates a potential infection chain across multiple customer organizations.

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.” They added: “So we have confirmed what the toolkit is built to do, and we have no evidence of successful exploitation and no evidence of a bypass at this time.”

Huntress separately reported that the console takeover attempt failed in every recovered host log it examined. Blackpoint's test against a current ScreenConnect client found the existing security fix prevented execution, so neither team has evidence of a successful worm-like attack or a bypass.

What does this change for MSPs?

ConnectWise has disabled five potentially related third-party extensions across approximately 400 partner environments. The company stressed that the presence of those extensions does not mean the environments were compromised.

For MSPs, the practical change is straightforward: treat a routine support session as a possible attack vector, not just a troubleshooting channel.

The researchers recommend:

• Disabling affected third-party extensions
• Updating ScreenConnect clients
• Investigating unauthorized remote-access installations
• Reviewing Run Command and Toolbox activity for signs of compromise
• Avoiding interactive ScreenConnect sessions with potentially infected endpoints and using separate security tools to investigate systems

The distinction that matters to an MSP is stark: one compromised customer endpoint versus potential access across an entire client portfolio.