ScreenConnect: commands pushed through Run Command to at least 288 managed endpoints at 48 Huntress customers within 90 minutes on 2026-11-11 installed a rogue second client and the SCKit toolkit; Huntress links the activity to the RMM+ extension, whose versions 1.0.31 and 1.0.32 accepted a blank access key
ScreenConnect: rogue clients pushed to 288+ endpoints; Huntress ties it to RMM+ extension with blank access key
Defender actions
- On every ScreenConnect instance your organisation or its IT providers run, review Run Command and Toolbox history and the instance audit logs for executions nobody started, including before 2026-11-11, check managed endpoints for a second ScreenConnect client service, and disable the five named extensions (on-premises instances by hand), RMM+ versions 1.0.31 and 1.0.32 first because they accept a blank access key; open no interactive session to a suspect host, use EDR live response or WinRM, because a session can trigger the toolkit to spread to the technician's workstation.
Analysis
On 2026-11-11 Huntress observed an operator using access to several cloud-hosted ScreenConnect panels to run commands as SYSTEM on groups of managed endpoints through the Run Command feature, hitting at least 288 hosts at 48 organisations that use Huntress within 90 minutes (Huntress, 2026-11-11). Each host checked for a ScreenConnect client, silently installed an attacker-controlled one, wrote a dropper and fetched SCKit, a 16-file toolkit delivered encrypted whose decryption values the server issues against the requesting machine's UUID (Huntress, 2026-11-11). The kit adds Defender exclusions, installs a second attacker-controlled client, sets the legitimate client to manual start so the attacker's copy replaces it, and runs a per-host executable from a scheduled task (Huntress, 2026-11-11).
Huntress's later update says the activity seems related to RMM+, a third-party extension that bypasses ScreenConnect's user accounts, roles and MFA and authenticates requests with a shared access key: versions 1.0.31 and 1.0.32 accepted a blank key when an administrator had never set one, commands reached endpoints across several instances within minutes with no corresponding login activity and were linked in the logs to RMM+; most RMM+ installations it saw were legitimate (Huntress, 2026-11-11). ConnectWise suspects the actor used independent third-party extensions that partners may have added, and disabled five (Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link) in about 400 partner environments; on-premises customers must disable them by hand (BleepingComputer, 2026-11-11); Huntress says ConnectWise had not yet identified an initial access vector or the full scope (Huntress, 2026-11-11). Huntress reconstructs a second stage meant to spread through the connecting technician's panel but saw no successful jump (Huntress, 2026-11-11). Huntress says sequential attacker tags suggest other MSPs were compromised earlier; BleepingComputer found a batch script first uploaded on 2026-07-25 that references one of Huntress's rogue client IDs, its link to this campaign unclear (BleepingComputer, 2026-11-11).
Cited evidence
On November 11, 2026, Huntress observed an operator using access to multiple cloud-hosted ScreenConnect panels to push commands to groups of managed endpoints.
The legitimate installation of ScreenConnect is then stopped, set to manual start, and the attacker controlled copy of ScreenConnect positioned to replace it.
Disabling these 3rd party extensions is a precautionary containment measure. It does not establish that unauthorized software, persistence mechanisms, or access already present on affected devices has been removed
versions 1.0.31 and 1.0.32 contained a serious authentication flaw
Sources3
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.