A new worm-like malware toolkit named SCKit was deployed in the recent ScreenConnect attacks targeting managed service providers (MSPs), designed to spread from infected customer devices to MSP technicians' computers and compromise additional managed networks.

The malware toolkit uses a worm-like technique that exploits a previously patched ScreenConnect vulnerability, CVE-2026-84869, to execute malicious code on a technician's workstation when they connect to an infected device.

However, researchers at Huntress and Blackpoint Cyber say they have not observed successful exploitation of this flaw during the attacks, with Blackpoint confirming that the exploit failed in testing against a patched ScreenConnect client.

The findings follow yesterday's widespread ScreenConnect attacks, in which 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.

ScreenConnect is a remote access and support platform used by MSPs and IT teams to remotely manage and troubleshoot customer devices.

According to an updated Huntress report, the attacks compromised at least 288 endpoints across 48 organizations, with all of the affected devices targeted within 90 minutes. Approximately one-third of those systems were affected within the first 10 minutes.

Huntress also believes the initial access was through RMM+, a third-party ScreenConnect extension that lets external management tools interact with ScreenConnect sessions without using the standard technician console.

The researchers found that RMM+ versions 1.0.31 and 1.0.32 contained an authentication flaw that could allow attackers to execute commands without authenticating to ScreenConnect or completing multifactor authentication.

RMM+ uses a shared access key to authenticate requests rather than ScreenConnect's normal user accounts and authentication mechanisms. However, the vulnerable versions allowed the access key to remain blank if an administrator had never configured one.

When this occurred, an attacker could supply an empty access key and pass the extension's authentication check, allowing them to issue remote commands through the ScreenConnect environment.

Huntress says this matches the activity observed during the attacks, where commands were executed across multiple ScreenConnect instances without corresponding user login activity, and logs linked the commands to RMM+.

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

SCKit attempts to spread through ScreenConnect sessions

In separate analyses, Huntress and Blackpoint Cyber examined SCKit, a collection of 16 scripts and components developed to establish persistent remote access and spread between systems managed through ScreenConnect.

Blackpoint Cyber's Adversary Pursuit Group (APG) recovered the malware's loader directly from attacker-controlled infrastructure and decrypted subsequent stages to obtain the complete loader and a ScreenConnect installer used in the attacks.

The attackers first deploy additional ScreenConnect Access clients configured to connect to servers under their control for persistent remote access even if the original MSP ScreenConnect session is terminated.

However, SCKit's more novel capability is its attempt to turn a legitimate MSP remote support session into an attack against the technician initiating it.

The toolkit includes a component called RelayTrap, which is designed to replace the legitimate ScreenConnect Guest process running on an infected endpoint and wait for an MSP technician to establish an interactive connection.

Rather than dropping a precompiled executable, the attackers store RelayTrap as a C# source code file named RelayTrap.cs on their infrastructure.

The source code is then downloaded to compromised devices, where a PowerShell script compiles it locally into an executable.

A separate component called TrapWatch monitors ScreenConnect services and prepares the replacement Guest process to intercept incoming support sessions.

When an MSP technician connects, RelayTrap attempts to send a malicious file in the opposite direction of a normal remote-support operation, from the infected customer endpoint to the technician's workstation.

The technique attempts to exploit CVE-2026-84869, a critical ScreenConnect client-side file-transfer vulnerability that ConnectWise patched in version 26.6.5.

Under normal circumstances, ScreenConnect allows technicians to send files to managed endpoints and execute them remotely. Instead, the vulnerability potentially allows a malicious Guest to send a file back to the technician and have it executed.

The recovered source code also contains extensive comments explaining its functionality, compatibility workarounds, and previous coding errors, giving it the appearance of LLM-generated code.

Huntress also noted that RelayTrap appears to have been generated using a large language model.

Once running on a technician's workstation, other SCKit components attempt to steal ScreenConnect authentication cookies from web browsers, which could allow attackers to hijack the technician's authenticated management session without requiring their 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 the platform's Shared Toolbox.

This creates a worm-like infection chain in which a compromised customer endpoint could infect an MSP technician's workstation, steal their management session, and use that access to compromise additional endpoints across other customer organizations.

However, Huntress and Blackpoint Cyber have not seen this worm-like behavior succeeding during the current campaign.

Blackpoint researchers Sam Decker and Nevan Beal told BleepingComputer that they reproduced the toolkit's attempted exploit against a current ScreenConnect client and found that the existing security fix prevented execution.

"The Guest side queued the transfer, but the current client never requested or ran the payload," the researchers explained.

"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 similarly reported that the console takeover attempt failed in every recovered host log it examined.

MSPs are urged to disable the affected third-party extensions, update ScreenConnect clients, investigate unauthorized remote-access installations, and review Run Command and Toolbox activity for signs of compromise.

Both research teams also recommend avoiding interactive ScreenConnect sessions with potentially infected endpoints and instead using separate security tools to investigate systems.