288 hosts in 90 minutes: how the attack unfolded
At 17:47 UTC on Wednesday 11 November, Huntress saw something wrong across several cloud-hosted ScreenConnect panels at once. An operator was pushing the same Run Command to groups of managed endpoints, and the command installed a second, attacker-controlled ScreenConnect client plus a toolkit Huntress calls SCKit. Within 90 minutes, at least 288 hosts across 48 organisations were hit, and about a third of them fell in the first 10 minutes. The Register corroborated the count the next day, and BleepingComputer first reported the attacks on the night of 11 November.
The striking part is what the logs did not show. There was no corresponding login activity, and the commands in the logs reviewed were linked to RMM+, a third-party ScreenConnect extension. The likely access route bypassed ScreenConnect’s normal user accounts through RMM+, although the initial method used to access the panels remains unconfirmed.
ScreenConnect is one of the most widely deployed remote-management tools: Acronis reports ScreenConnect on about 9% of the more than 1.8 million managed endpoints in its dataset, behind only TeamViewer at more than 16%. A compromised panel can expose every customer environment it manages, which helps explain how activity through a small number of MSP environments can affect dozens of organisations within a short period.
The likely door was a blank access key, not a zero-day
Huntress’s assessment is that the entry point appears to have been RMM+, an extension that lets another tool manage ScreenConnect sessions without a technician working through the console. ConnectWise said the initial access method remained under investigation, and Blackpoint did not establish the extensions as the initial-access route. Versions 1.0.31 and 1.0.32 contained a serious authentication flaw: if an administrator had never configured the extension’s access key, RMM+ would accept a blank one. The extension bypasses ScreenConnect’s user accounts, roles and multi-factor authentication, authenticating requests with a shared access key stored in its settings. The setting’s own description tells the admin to set a strong key, but its default value is empty.
ConnectWise posted an advisory at 22:45 UTC on 11 November, identifying five independent third-party extensions that may be associated with the activity and disabling them across about 400 cloud-hosted partner environments as a precaution; on-premises partners must disable them manually. The company said it had found no evidence of a compromise of ConnectWise infrastructure or a vulnerability in ScreenConnect itself, and the 400 environments were flagged because they had the extensions installed, not because they were necessarily compromised. The attacks affected ScreenConnect versions 26.6.6.9747 and 26.7.6.9783, the latest releases at the time, which means patching ScreenConnect itself would not have stopped this.
The scariest part of this story is not the malware. It is how ordinary the door was: an access key left blank, on a third-party extension. And this is the third major security incident involving ConnectWise products in just over two months, although the three incidents involved different products and attack methods. In September, Huntress disclosed rogue ScreenConnect clients spreading through a file-transfer flaw, CVE-2026-84869, which ConnectWise fixed in version 26.6.5 and CISA added to its exploited-vulnerabilities catalogue on 11 September. In October, ConnectWise found suspicious activity tied to its Cloud Backup app identities, with unauthorised sign-ins across 162 Microsoft 365 tenants, later 173. In November, the door was a third-party extension with a blank key. The common thread is not the vulnerability. It is that one MSP panel reaches every customer it manages.
SCKit: the trap waiting for your technician
SCKit is a package of 16 files, PowerShell scripts, batch scripts, .cmd files and configuration data, built to spread the infection sideways. The Run Command first checks for an existing ScreenConnect client, then downloads an attacker-controlled installer and installs it silently. It writes a base64-encoded dropper, fetches a keyed copy of the toolkit for that specific machine, and extracts it to C:\ProgramData\RelayTrap. The legitimate ScreenConnect client is stopped and set to manual start, Defender exclusions are added, and a scheduled task named TrapWatch is created, running as SYSTEM. Some of the toolkit’s C# code appears to have been generated using a large language model, based on the unusually detailed comments.
Then comes the trap. RelayTrap replaces the legitimate ScreenConnect Guest process on an infected endpoint and waits. When a technician connects to that endpoint, a file transfer takes place 2.5 seconds after the connection is established to deliver a payload onto the technician’s workstation, which would then run code designed to steal the technician’s .aspxauth session cookie and replay it against the panel to obtain tokens for enumerating the other sessions that technician can access. A component called ToolboxRelayUploader is built to push a payload to the panel’s Shared Toolbox, so a single panel request can run it as SYSTEM on every reachable session, and roughly 60 seconds later it deletes the toolbox item.
Huntress also noticed the attackers tagging each compromised provider with a sequential number, and the tags it observed start partway through the sequence, which suggests earlier attacks it has not detected yet. No victim organisation has been publicly named in the reporting reviewed so far.
The worm that didn’t worm
For all its design, the trap has not been observed working. Huntress says it has not observed the method spreading successfully, and the console-takeover attempt failed in every recovered host log it has checked so far. Blackpoint Cyber reproduced the toolkit’s attempted exploit against a current ScreenConnect client and found the existing security fix prevented execution, confirming the toolkit’s intended function but finding no evidence of successful exploitation or a bypass. The flaw SCKit tries to use, CVE-2026-84869, is a critical client-side file-transfer vulnerability that ConnectWise patched in version 26.6.5, and the worm’s central trick only works against unpatched clients.
That does not make the campaign harmless. Affected machines have been observed becoming reinfected within minutes of being taken out of isolation, because the malware had not been properly removed, and ConnectWise has warned that disabling the extensions and resetting credentials alone may not remove unauthorised software, persistence mechanisms or access already established on endpoints. Sophos has also observed unauthorised ScreenConnect client deployments following the same method, according to The Hacker News, which means the campaign’s first stage is spreading even while its second stage stalls.
We still do not know who ran this campaign, or how many providers were hit before Huntress started counting.
What should MSPs do right now?
If you run ScreenConnect, check your environment now, even if you have not received an alert. Look for unexpected mass activity in Run Command and Toolbox history, and check for an unauthorised second ScreenConnect client on managed endpoints. The indicators below are the ones Huntress and Blackpoint published.
- Review your ScreenConnect Run Command and Toolbox history for any command or tool you did not initiate yourself.
- Do not open a ScreenConnect session to a suspect host; use EDR live response, WinRM, or another tool.
- Isolate any affected host and keep it isolated until the rogue client and its persistence mechanism are fully removed.
- Remove the unauthorised ScreenConnect client, the TrapWatch scheduled task, the RelayTrap folder and the toolkit files in the temp folder.
- Delete the RelayTrapLiteAlert value from the Windows Run registry key, and confirm no other persistence entries remain.
- Verify the legitimate ScreenConnect client separately before removing any ScreenConnect product from the affected host.
- Update the Host and Guest clients on every technician workstation to version 26.6.5.9742 or later, as Blackpoint recommends.
- From a clean device, end active ScreenConnect web sessions, rotate affected credentials and revoke exposed browser and identity-provider sessions.
- Check any technician workstation that connected to an affected host since 11 November, and treat it as exposed until cleared.
What to watch next
ConnectWise has not yet published a complete root-cause explanation. Its investigation remains ongoing, although its subsequent updates have identified the third-party extension family as a possible access route; a CVE has also been assigned to the extension flaw. The sources reviewed for this article do not confirm that RMM+ has shipped a fix. Huntress is still confirming the full set of affected hosts as telemetry arrives, and its count of 288 hosts and 48 organisations may rise. Huntress told The Hacker News that the exact method of initial panel access remains unclear, with its earlier telemetry pointing to compromised credentials or hijacked operator sessions, which sits in tension with its later finding that the commands were linked to RMM+. Whether CISA issues an advisory for the RMM+ flaw is an open question, as is whether the technician trap ever spreads in the wild. Huntress advises affected parties to audit ScreenConnect Run Command and Toolbox history and use the instance audit logs to investigate panel access.
This story is not connected to N-able’s deliberate shutdown of hosted N-central environments on 9 November; N-able is a separate vendor with a separate product, and no connection has been reported between the two incidents. It is also distinct from the September rogue-client campaign, which used the file-transfer flaw rather than an extension, and from the October Cloud Backup incident, which abused app identities rather than a panel extension.
