SCKit toolkit tried to turn ScreenConnect support sessions against MSP technicians

A malware toolkit called SCKit was deployed in the ScreenConnect attacks that hit managed service providers, according to analyses from Huntress and Blackpoint Cyber reported by BleepingComputer on November 12. Its most interesting component is an attempt to reverse the direction of a normal remote support session: instead of the technician sending a file to the customer endpoint, the infected endpoint tries to send one back to the technician and get it run.

That step didn't work. Blackpoint's Sam Decker and Nevan Beal reproduced the attempt against a current ScreenConnect client and found the fix held. "The Guest side queued the transfer, but the current client never requested or ran the payload," they told BleepingComputer. Huntress says the console takeover attempt failed in every recovered host log it examined. Neither team has seen the worm-like behaviour succeed in this campaign.

What happened

The attacks themselves came first. Attackers got 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's updated report puts the damage at 288 endpoints across 48 organizations, all targeted within 90 minutes, with roughly a third hit in the first 10 minutes.

Huntress believes the way in was RMM+, a third-party ScreenConnect extension that lets external management tools talk to ScreenConnect sessions without going through the technician console. Versions 1.0.31 and 1.0.32 had an authentication flaw: the extension authenticates with a shared access key rather than ScreenConnect user accounts, and in those versions the key could stay blank if an administrator had never set one. An attacker could supply an empty key, pass the check, and issue remote commands. Huntress says that matches what it saw, with commands running across multiple instances without matching user logins and logs tying them to RMM+.

ConnectWise disabled five potentially related third-party extensions across approximately 400 partner environments. The company stressed that having those extensions installed doesn't mean an environment was compromised.

How SCKit works

The toolkit is 16 scripts and components. Blackpoint recovered the loader from attacker-controlled infrastructure and decrypted the later stages, including a ScreenConnect installer used in the attacks.

The straightforward part is persistence: attackers deploy extra ScreenConnect Access clients pointed at servers they control, so access survives the MSP ending the original session.

The novel part is RelayTrap. It replaces the legitimate ScreenConnect Guest process on an infected endpoint and waits for a technician to connect. TrapWatch monitors ScreenConnect services and gets the replacement ready. RelayTrap is stored as C# source, RelayTrap.cs, downloaded to the compromised device and compiled locally by a PowerShell script rather than shipped as a prebuilt executable. The recovered source carries detailed comments about its own functionality, compatibility workarounds and earlier coding mistakes, which Huntress and Blackpoint both read as a sign of LLM-generated code.

The intended chain after that: land on the technician's workstation, steal ScreenConnect authentication cookies from browsers, and use the technician's existing session and permissions to enumerate endpoints and push commands through legitimate features including Shared Toolbox. One compromised customer endpoint could then reach other customers' networks.

HackZoneLabs assessment

The headline risk here is the supply-chain shape, not the CVE. A technician's workstation sits inside the trust boundary of every customer they support, and a session cookie lifted from a browser skips both the password and the MFA prompt. That's the part worth worrying about, and it's the part that didn't need a vulnerability to work.

On the exploit itself, we'd take the failed reproduction at face value: two independent teams, one of them testing against a current client, and Huntress finding no success in any host log it recovered. The flaw is patched in ScreenConnect 26.6.5, and the attackers appear to have been working from a version of the technique that no longer lands. That doesn't make the toolkit harmless. It means the worm-like spread described in the reporting is an attempt, not an observed outcome, and coverage that treats it as a live self-spreading incident is ahead of the evidence.

We'd also separate the two failures. The extension flaw is what let attackers in, and it's a configuration-dependent bug: a blank shared key. The client flaw is what they tried next. Fixing one doesn't address the other.

What remains unknown

Nobody has published how many MSPs or customer organizations were affected beyond Huntress's 288 endpoints and 48 organizations, and that figure covers the endpoints Huntress could see. Whether other incident responders found more isn't stated. The reporting doesn't say how the attackers first reached the cloud-hosted ScreenConnect environments, or whether any technician workstation was actually compromised by RelayTrap before the exploit failed. It also doesn't say whether the rogue Access clients are still installed anywhere.

What to check first

• Disable the affected third-party extensions, RMM+ included, and check whether a shared access key was ever configured.
• Update ScreenConnect clients to 26.6.5 or later. The server side isn't affected by this flaw, per the vendor description.
• Look for unauthorized ScreenConnect Access clients and review Run Command and Toolbox activity for commands nobody remembers issuing.
• Both research teams recommend not opening interactive ScreenConnect sessions with endpoints you suspect are infected. Investigate those systems with separate tools instead.

CVE references

CVE-2026-84869