SCKit ScreenConnect worm: 288 PCs hit, RMM+ 1.0.31/1.0.32 flaw

Attackers used cloud-hosted ScreenConnect panels to push a worm-like toolkit called SCKit onto at least 288 computers at 48 organizations on 11 November 2026, and a second wave followed on 13 November. The toolkit sets a trap for IT technicians: when a support person connects to an infected machine, it tries to take over their session and spread to every other customer they manage. Huntress, Blackpoint Cyber and Microsoft all say the spreading part has not been seen to work so far, but the rogue remote-access clients it leaves behind are real, and removing them is not enough to clean a machine.

Key points

• Huntress saw an operator use ScreenConnect's Run Command to install attacker-controlled ScreenConnect clients and the SCKit toolkit on 288 hosts across 48 organizations on 11 November; all were reached within about 90 minutes, roughly a third within the first 10.
• A second wave on 13 November hit 205 hosts across 41 organizations, using new infrastructure, according to Huntress.
• Huntress believes initial access came through RMM+, a third-party ScreenConnect extension: versions 1.0.31 and 1.0.32 accepted an empty access key when an administrator had never set one. Microsoft says the entry method is still under investigation.
• ConnectWise disabled five third-party extensions in about 400 partner environments and says it found no vulnerability in ScreenConnect itself; on-premises partners must disable them on their own servers.
• Every technician client should run ScreenConnect 26.6.5 or later, which fixes CVE-2026-84869 (CVSS 9.9), the flaw SCKit tries to use to jump from an infected endpoint to the technician.

What to do

Who is affected. Managed service providers and internal IT teams that run ScreenConnect, especially on-premises servers with the RMM+ extension (also sold as RMM Plus, Labtech Plus and the two "Password Link" variants) installed. Cloud-hosted partners had the five extensions disabled by ConnectWise on 11 November.

Do now.

1. Keep the five extensions disabled: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. If you need RMM+, set a strong access key rather than leaving it blank. Review the extensions' configuration history.
2. Check that every technician client reports ScreenConnect 26.6.5 (build 26.6.5.9742) or later. Microsoft points out that updating a cloud console does not update the clients installed on technicians' machines.
3. Open the panel's Run Command and Shared Toolbox history and look for mass activity you did not start. List every installed Access client and compare its relay address with the ones you approve.
4. Hunt on endpoints for the folder C:\ProgramData\RelayTrap\, a scheduled task named TrapWatch, a RelayTrapLiteAlert value in the HKLM Run key, sc.msi in C:\Windows\Temp, and new Microsoft Defender exclusions for msiexec.exe or powershell.exe.
5. Do not investigate a suspect machine through ScreenConnect. Use WinRM, Defender for Endpoint live response or another separate channel. If a technician already connected to a suspect machine, treat that technician's workstation as exposed.
6. Terminate active ScreenConnect web sessions from a clean device, revoke browser and identity-provider sessions, and rotate credentials. Do not run the toolkit's own cleanup scripts: Microsoft warns they can restart the dropper.

Indicators (defanged), as published by the researchers: IPs 185.99.255[.]28, 155.94.150[.]39 and 185.241.211[.]197; domains sc.payproofkit[.]com, cdn007-digitaldownloads[.]com, soxnewwork.homedns[.]org, newnewnew.gotdns[.]org and ns.mo7sen[.]dev; rogue client IDs 2588ef5c15954b10 and ed630cc2c873b091. Huntress notes that file hashes are weak indicators because the scripts are rebuilt per host.

What happened

According to Huntress, the first suspicious activity appeared at about 17:47 UTC on 11 November 2026. An operator with access to cloud-hosted ScreenConnect panels used the Run Command feature to execute commands as SYSTEM on managed endpoints. The commands silently installed an attacker-configured ScreenConnect client (sc.msi) and wrote a small dropper, sckit-run.bat. The dropper fetched a decoder script and a host-specific SCKit package. The package is encrypted, and the decryption values come back from the server based on the machine's identity, so the same file will not decode on another machine. Microsoft describes the same chain and says the key is derived from the device's MachineGuid.

At 22:45 UTC the same day, Huntress's timeline notes, a ConnectWise advisory named five third-party extensions that might be involved and disabled them across about 400 partner environments. ConnectWise said it "found no evidence of a compromise of ConnectWise infrastructure or a vulnerability in ScreenConnect itself", and said its first assessment was that a threat actor had abused independent third-party extensions (CyberScoop). It stressed that an extension being present does not mean an environment was compromised.

On 13 November at 16:12 UTC a second wave began on new infrastructure and reached 205 hosts across 41 organizations, Huntress reports. In that wave a client was hosted at 185.241.211[.]197, which Huntress links to a bulletproof hosting provider, and some hosts got a rogue service named "Windows Update Agent" running as LocalSystem. Blackpoint's SOC also logged a second wave aimed at on-premises ScreenConnect servers where the mitigations had not yet been applied.

No one has named an actor. CyberScoop reports that neither Huntress nor ConnectWise has attributed the activity, and that the initial access method and full scope remain under investigation.

Wave 1, 11 Nov288

Wave 2, 13 Nov205

Hosts hit by SCKit, by wave (Huntress) (hosts)

	hosts
Wave 1, 11 Nov	288
Wave 2, 13 Nov	205

Source: Huntress, SCKit worm report

Background

ScreenConnect is a remote-support tool that MSPs use to reach customers' computers. A technician's console can run commands on many endpoints at once (Run Command) and can push files to every reachable session (the Shared Toolbox). That reach is the point of the product, and it is also why a stolen console is worth so much to an attacker.

RMM+ is one of several extensions that let other tools drive ScreenConnect. Huntress says it works outside ScreenConnect's user accounts, roles and multi-factor authentication and relies only on a shared access key. In versions 1.0.31 and 1.0.32 that key could stay blank if an administrator never set one, and an empty key then passed the check. Huntress reports that the commands it saw across several ScreenConnect instances had no matching user logins, and that logs tie them to RMM+. Its caveat matters: the activity "seems to be related" to RMM+, and most RMM+ installs it reviewed looked legitimate, usually added for a project and left in place, so how many were abused is not established. CyberScoop's report does not say who develops RMM+.

The second thread is CVE-2026-84869, a critical flaw in the ScreenConnect client, rated 9.9 on CVSS, which ConnectWise fixed in version 26.6.5 on 8 September 2026. Huntress describes it as allowing file transfer and execution through an active session without the host's approval. Blackpoint adds that it is a guest-to-host flaw in the technician's client (not the server) and affects builds earlier than 26.6.5.9742. An attacker needs control of an existing guest session to use it, and Blackpoint's researchers found no unauthenticated, internet-facing path against arbitrary servers.

How it works

The toolkit has 16 scripts and components, according to BleepingComputer's summary. The ones that matter:

• Persistence. A second attacker-controlled ScreenConnect client, plus a TrapWatch scheduled task that runs as SYSTEM every 10 seconds. Defender exclusions are added. Removing only the rogue client leaves the rest in place, and Huntress saw hosts reinfected after isolation was lifted.
• RelayTrap. A C# file that TrapWatch compiles on the victim machine. It replaces the legitimate ScreenConnect guest process, so the host looks normal, and waits for a technician to connect. When someone does, it tries to send a file-transfer-and-run request back to the technician's client, which is where CVE-2026-84869 comes in.
• Session theft. Components try to read the .ASPXAUTH login cookie from Chrome, Edge, Opera and Opera GX, by database queries and by scanning browser memory. A stolen cookie would let the attacker act as the technician without a new MFA prompt.
• Spread. With the technician's cookie, the worm would enumerate other sessions, upload a payload to the Shared Toolbox and broadcast it so it runs as SYSTEM on every reachable machine.

Huntress and Blackpoint agree that the spread has not worked in what they have seen. Blackpoint's researchers reproduced the exploit attempt against a current client and wrote: "The Guest side queued the transfer, but the current client never requested or ran the payload." Huntress says the console-takeover attempt failed in every recovered host log it checked so far. Blackpoint also found bugs in the code, including a SQLite parsing defect that discards cookie rows. BleepingComputer reports that Huntress thinks RelayTrap looks LLM-generated because of its heavy commenting; treat that as an impression, not a finding.

What it means

For MSPs, the lesson is about the shape of the risk. The fix for CVE-2026-84869 blocked the part of the toolkit that matters most, but only on machines that run the fixed client, and a console update does not change what is installed on a technician's laptop. A patch level that nobody checks is the gap.

For anyone who uses extensions that sit beside a remote-management console, the lesson is that they can bypass the console's own protections. RMM+ did not go through accounts, roles or MFA. Blackpoint found no direct technical link between the disabled extensions and SCKit's RelayTrap or cookie-theft code, which is a reminder that initial access and the toolkit are separate problems that need separate fixes.

For the customers of an affected MSP, the practical question is whether their provider has checked for a second ScreenConnect client on their machines. Ask for the provider's findings rather than assuming the cloud-side mitigation covered it.

What we don't know yet

• How the attackers got in. Huntress points to RMM+, Microsoft says the entry method remains under investigation, and ConnectWise's investigation is open.
• Who is behind it. No attribution has been published.
• How many installs were abused. The 288 and 205 hosts are what Huntress observed; the total may be higher.
• Whether the worm can work. It has failed against patched clients in the logs reviewed, but that is a statement about those logs, not a guarantee. Huntress's own report mentions a counter in the installer pattern that suggests more hosts than it has confirmed, so we do not rely on it.
• Whether the latest ScreenConnect builds are affected in some other way. Huntress says it is working with ConnectWise on this; we have no confirmation either way.

What to watch next

ConnectWise has said it will update its advisory as facts are confirmed. Watch for a root-cause statement on the initial access, a fixed RMM+ release or its removal, and updated indicators from Huntress and Blackpoint. If you run ScreenConnect on-premises, check the advisory again before assuming the extension list is final.

Sources

• Huntress: SCKit worm installs rogue ScreenConnect clients and session cookie relays
• Blackpoint Cyber: ScreenConnect attack and SCKit
• Microsoft Security: SCKit abuses ScreenConnect to deploy remote access and target technician sessions
• CyberScoop: Rogue remote-access campaign spread through ScreenConnect add-on, researchers say
• BleepingComputer: New worm-like SCKit malware targets MSPs in ScreenConnect attacks