SCKit worm: rogue ScreenConnect clients on 288 endpoints in 48 organizations, RMM+ blank key

Huntress says an attacker used cloud-hosted ScreenConnect panels run by managed service providers (MSPs) to push commands that installed rogue ScreenConnect clients and a toolkit it calls SCKit on at least 288 endpoints across 48 customer organisations on 11 November 2026. ConnectWise disabled five third-party ScreenConnect extensions in about 400 partner environments, and Huntress later tied the activity to one of them, RMM+, whose versions 1.0.31 and 1.0.32 accepted a blank access key. Our first version of this article, written from BleepingComputer's early report, counted 286 endpoints across 47 organisations; Huntress's own post now says 288 and 48.

Key points

• Huntress first saw the activity at about 17:47 UTC on 11 November 2026, and all 288 hosts were hit over roughly 90 minutes, about a third in the first 10 minutes.
• The attacker used ScreenConnect's Run Command feature in compromised, cloud-hosted panels to install a second, attacker-controlled ScreenConnect client and SCKit, a 16-file toolkit that adds Defender exclusions and intercepts session cookies.
• ConnectWise published an advisory at 22:45 UTC on 11 November and disabled five third-party extensions (Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, RMM+ Password Link) across about 400 partner environments; on-premises partners must disable them themselves.
• Huntress says RMM+ 1.0.31 and 1.0.32 accepted a blank key when the administrator never set one, bypassing ScreenConnect accounts, roles and MFA; ConnectWise says it has no evidence of a ScreenConnect software vulnerability or a compromise of its own infrastructure.
• The initial access route is not confirmed, and Huntress has not observed the designed second stage (hopping to technician workstations) succeed.

What to do

Who is affected. MSPs and IT teams that use ConnectWise ScreenConnect, especially cloud-hosted panels with any of the five extensions installed, and their customers' endpoints. ConnectWise stresses that having an extension installed does not by itself mean compromise.

1. Disable the five extensions (Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, RMM+ Password Link) if you run ScreenConnect on premises. ConnectWise cannot do it for you there.
2. Review panel history. Check Run Command and Shared Toolbox history for mass activity you did not start, and look for unexpected second ScreenConnect clients on endpoints and for a participant named "Addmin". Huntress lists rogue client IDs 2588ef5c15954b10 and ed630cc2c873b091; Sophos reports the same two as deployed instances.
3. Do not investigate through ScreenConnect. Huntress and ConnectWise advise using EDR live response, WinRM or another tool outside ScreenConnect, and Huntress treats any technician workstation that connected to a suspect host as potentially exposed.
4. Isolate, then clean. Huntress reports that isolation alone does not remove persistence and some hosts were reinfected after isolation was lifted. It lists the rogue client service, the TrapWatch scheduled task, C:\ProgramData\RelayTrap\, toolkit files in %TEMP% and the RelayTrapLiteAlert value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run for removal, and says to verify the legitimate ScreenConnect client separately before deleting anything.
5. Revoke sessions and rotate credentials. End active ScreenConnect web sessions and revoke browser and identity-provider sessions, because the toolkit steals session tokens.
6. Hunt for indicators (defanged): 185.99.255[.]28, 155.94.150[.]39, sc.payproofkit[.]com, ns.mo7sen[.]dev, cdn007-digitaldownloads[.]com, newnewnew.gotdns[.]org and soxnewwork.homedns[.]org. Huntress notes file hashes are weak indicators because the scripts are rebuilt with different embedded values.

What happened

Huntress says that on 11 November it saw an operator using cloud-hosted ScreenConnect panels to send commands to groups of managed endpoints, running as SYSTEM. The commands installed rogue ScreenConnect clients and SCKit. Huntress counted at least 288 hosts across 48 of its customer organisations and said the numbers were climbing; BleepingComputer's first report quoted "286+ endpoints" and 47 organisations.

ConnectWise published its advisory at 22:45 UTC. It disabled the five third-party extensions as a precaution, saying about 400 partner environments had at least one of them, and said it had not yet identified the initial access vector or the full scope. It said it had found no evidence that the incident involves a compromise of its infrastructure or a vulnerability in ScreenConnect. Sophos separately observed unauthorised client deployments using the same method, and traced them to three source ScreenConnect instance IDs.

At 11:34 pm ET on 11 November, Huntress updated its post to link the activity to RMM+, one of the disabled extensions.

How SCKit works

Huntress describes SCKit as 16 files (PowerShell, batch, .cmd and configuration files) delivered encrypted. The infected machine sends its UUID to the server, which returns the decryption values, so each host gets a machine-specific kit. According to The Hacker News, a Base64-encoded batch dropper (sckit-run.bat) fetches a PowerShell script (sckit-decoder.ps1) that launches it. Installation silently installs a rogue ScreenConnect client, adds Defender exclusions, and adds software restriction or AppLocker rules that block files pushed through ScreenConnect's temp folders.

The "relay trap" is the unusual part. Running as SYSTEM every 10 seconds, it stops the legitimate ScreenConnect client and takes over its connection slot, so the host still appears normal in the panel, and it is built to intercept the session cookie of a technician who connects. Huntress reconstructed a second stage from the scripts: with a stolen .aspxauth cookie the malware could enumerate other sessions the technician can reach, upload a payload to the panel's Shared Toolbox and broadcast a command so every reachable session runs it as SYSTEM, deleting the Toolbox item after about 60 seconds. Huntress says it has not observed this succeed, and the console-takeover attempt failed in every recovered host log it had checked. It also notes some scripts appear to be generated by a large language model, judging from detailed source references and comments.

Background

ScreenConnect is remote-support software that MSPs use to manage many customers' machines from one panel, which makes a panel account a very valuable target. Huntress says it launched a Rapid Response in September 2026 for similar worm-like activity, and that ConnectWise later patched CVE-2026-84869, a critical file-transfer vulnerability rated CVSS 9.9. Huntress does not present that flaw as the cause of this campaign, and ConnectWise says no ScreenConnect vulnerability is involved here.

According to The Hacker News, ConnectWise suspects abuse of third-party extensions, which expose an API that can run remote commands, protected by a passphrase the partner sets during setup. That fits Huntress's finding that RMM+ 1.0.31 and 1.0.32 accepted a blank key when none had been configured, since RMM+ bypasses ScreenConnect's user accounts, roles and MFA. Huntress says most RMM+ installations it saw were legitimate.

What it means

For MSPs the incident is a reminder that a remote-management panel is a single point of failure, and that third-party extensions can sit outside the vendor's authentication. A shared passphrase that can be left blank turns a convenience feature into a way around MFA. For the customers of MSPs, the question to ask a provider is whether it uses any of the five extensions and has reviewed its Run Command history.

It also shows the cost of cleaning up a persistent tool that looks legitimate. Because the attacker's client is a real ScreenConnect client, the host still appears manageable, and Huntress's advice to treat any ScreenConnect connection to an unfamiliar machine as unsafe follows from that.

What we don't know yet

• How the attacker obtained panel access. Huntress's assessment, as The Hacker News reports it, is compromised credentials or hijacked operator sessions, with no evidence of a new vulnerability; ConnectWise says its investigation is ongoing and is still validating whether the extensions were the route.
• The full scope. Huntress observed the attacker tagging each compromised MSP with a sequential number, and the tags start partway through the sequence, so other MSPs may have been hit earlier. An earlier batch script tied to a rogue client ID was uploaded to VirusTotal on 25 July 2026, according to BleepingComputer.
• Which ScreenConnect versions matter. Huntress's report names versions 26.6.6.9747 and 26.7.6.9783 in connection with the activity while ConnectWise reports no software flaw, so we treat the versions as unconfirmed.
• Whether the lateral movement from an endpoint to a technician workstation and onward has happened in practice.
• Who is behind it. No source attributes the campaign.

What to watch next

• ConnectWise advisory updates on the initial access vector and any new extension guidance.
• Huntress updates to its SCKit post, including more indicators and the outcome of the RMM+ analysis.
• Whether other MSP-tool vendors review similar extension ecosystems.

Sources

• Huntress: SCKit worm, rogue ScreenConnect clients and session cookie relays (primary)
• BleepingComputer: Active ScreenConnect attacks breach MSPs, impact dozens of organizations
• The Hacker News: ScreenConnect attacks target at least 288 endpoints across 48 organizations
• ConnectWise trust center advisories (we could not open this page; ConnectWise's statements are as reported by Huntress, BleepingComputer and The Hacker News)