Attackers deployed rogue ScreenConnect clients and SCKit malware across 288 endpoints

Huntress said a threat actor deployed rogue ScreenConnect clients (remote-access software) and SCKit malware across at least 288 endpoints in 48 organizations and six managed service providers on Nov. 11, 2026.

The intruders reached all 288 compromised hosts within 90 minutes, with roughly a third compromised in the opening 10 minutes. Suspicious activity began at about 17:47 UTC and targeted cloud-hosted ScreenConnect instances.

BleepingComputer reported an earlier tally of 286 affected endpoints across 47 organizations and six compromised MSPs, an update it said differed slightly from later Huntress totals. Huntress said victim numbers were still rising.

Huntress said attackers exploited RMM+, a third-party ScreenConnect extension that uses a shared access key to bypass authentication. RMM+ versions 1.0.31 and 1.0.32 set the access key to blank unless an administrator configured it, letting the extension accept an empty value and bypass ScreenConnect accounts, roles, and multifactor authentication. Huntress put it this way: “if an administrator had never configured the extension’s access key, RMM+ would accept a blank one.”

Most RMM+ installations Huntress encountered were legitimate project additions that were left behind, and its telemetry tied the activity to RMM+, with commands reaching endpoints within minutes and no matching login activity. Huntress said compromised credentials or hijacked operator sessions were the likely initial access route, though the exact method remained undetermined.

ConnectWise acted against five third-party ScreenConnect extensions across roughly 400 partner environments as a precaution on Nov. 11: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, and RMM+ Password Link. The vendor said the extensions expose an API that runs remote commands, protected by a passphrase the partner configured during setup, and stressed that their mere presence does not establish compromise.

Customers running ScreenConnect on-premises must disable the extensions themselves since ConnectWise cannot remove them remotely, and ConnectWise posted its advisory at 22:45 UTC on Nov. 11. The advisory confirmed that intruders accessed partner accounts without authorization and installed unauthorized remote-access software in customer environments.

ConnectWise said it saw no evidence that its infrastructure was compromised or that the ScreenConnect software contained a vulnerability. The company also said investigators had not yet determined the initial access method or the full scope.

Spike Brandt, a Huntress researcher and the firm’s principal threat intelligence incident commander, said the activity abuses legitimate functionality instead of exploiting a software vulnerability. Speaking to The Hacker News, Huntress said it had seen no evidence of a new vulnerability and that the exact panel-access method remained unclear. Huntress telemetry pointed to compromised credentials or hijacked operator sessions as the likely initial access route.

The rogue clients delivered SCKit, a malware toolkit that provides persistent backdoor access, session-cookie interception, and self-replication. As Huntress researchers Ben Nahorney and Susannah Matt described it: “The rogue clients deliver SCKit, a custom malicious toolkit that establishes persistent remote access and creates a relay trap for intercepting session cookies.”

SCKit arrives encrypted and is unlocked using a key derived from the infected Windows system’s UUID, while a base64-encoded dropper retrieves a second-stage script and a system-specific SCKit copy. Those opening commands ran with SYSTEM privileges on the endpoints, and SCKit components extract themselves to C:\ProgramData\RelayTrap before deleting temporary installation files.

Once deployed, the toolkit enforces trap and lockout policies, adds Microsoft Defender exclusions, drops a second attacker-controlled ScreenConnect client, halts the legitimate client, and schedules a TrapWatch task that compiles a host-specific executable. Huntress said the executable is rebuilt per host, making file hashes weak indicators.

The malware can move from a compromised endpoint onto a technician’s workstation and then to other endpoints reachable from that panel, while scripts steal the .aspxauth session cookie and attempt to replay it against the panel. But Huntress said: “To date we have not observed a successful jump from an infected endpoint to a technician workstation, or from that workstation to other endpoints.”

The attackers also uploaded a payload to the panel’s Shared Toolbox and broadcast a request instructing every reachable session to run it, with the Shared Toolbox item removed about 60 seconds after that broadcast. A file transfer occurred 2.5 seconds after a technician connected, retrieving a lateral-movement script from the compromised endpoint as part of the reconstructed path.

Indicators of compromise include the attacker relay 185.99.255[.]28 with hostname screen, the command-and-control (C2) domains newnewnew.gotdns[.]org and soxnewwork.homedns[.]org, possible C2 cdn007-digitaldownloads[.]com, and secondary C2 sc.payproofkit[.]com at 155.94.150[.]39 with hostname WIN-FB5CKHMU4E1. Huntress also listed stager ns.mo7sen[.]dev/EadF.php?p=4 and the attacker name Addmin, alongside rogue client IDs 2588ef5c15954b10 and ed630cc2c873b091.

Sophos observed similar unauthorized ScreenConnect client deployments from instance IDs d905b2b1b165d0a9, 4b8f4089ddaac6a9, and df1f7ef0cfacd0d8, and suspected those instances deployed malicious instances including 2588ef5c15954b10 and ed630cc2c873b091.

An earlier batch script, SSA-2026-STATEMENT-15518787.bat, was first uploaded to VirusTotal on July 25, 2026, and references the rogue client ID ed630cc2c873b091 seen in the current campaign. That script adds Defender exclusions, creates Startup and Run-key persistence, contacts amexsafekeyupdate.com, sends a Telegram notification, and attempts to install ScreenConnect MSI packages; its Social Security-themed filename suggests attackers may have used it in phishing for a different distribution campaign.

Huntress said the relationship between the July malware activity and the current ScreenConnect attacks remains unclear. In September 2026, Huntress responded to worm-like activity that built rogue ScreenConnect clients across customer environments, and ConnectWise patched critical file-transfer vulnerability CVE-2026-84869 on Sept. 11, 2026. The fix affects client versions before v26.6.5 but not servers, and ConnectWise has not confirmed any link between the rogue-client campaign and the file-transfer flaw.

Earlier rogue-client incidents began with social engineering, and earlier payloads included cryptocurrency mining, tunneling, ScreenConnect installations, security-control changes, and persistence. Huntress said it has observed a significant increase in 2026 attacks using legitimate remote monitoring and management (RMM) software as an initial payload, describing RMM abuse as a top attack vector tracked over the past year.

ScreenConnect lets MSPs and IT teams remotely manage customer devices, and the campaign compromised six MSPs. The intrusion can jump from one compromised endpoint to a technician’s workstation and then onward to other endpoints reachable from that panel.

ConnectWise instructed partners not to re-enable or reinstall the five extensions until further guidance, and on-premises customers must disable them manually because the vendor cannot do so remotely. Partners should review authentication logs, extension records, administrative activity, Run Command history, and Toolbox records, and check Run Command history even without alerts. ConnectWise warned that disabling the extensions does not by itself remove malware, persistence, or access the attackers may already have established.

ConnectWise urged technicians to avoid interactive sessions with potentially compromised devices, and Huntress said to investigate from a clean device using EDR live response, WinRM, or another out-of-band CLI tool instead of ScreenConnect. Isolate affected hosts until cleanup completes, though isolation alone does not remove persistence and some affected systems have been seen reinfecting soon after isolation ends.

Remove the rogue client service, the TrapWatch task, C:\ProgramData\RelayTrap\, %TEMP% toolkit files, and the RelayTrapLiteAlert Run value, verifying the legitimate ScreenConnect client before removing anything. Revoke access by ending active ScreenConnect web sessions, rotating credentials, and revoking exposed browser and identity-provider sessions, and do not return hosts to service until partners have removed the rogue client and persistence and ruled out reinfection.

Huntress said file hashes make weak indicators since every rebuild uses different embedded values and each host receives its own compiled trap executable, so defenders should rely on behavioral indicators instead. Auditors should check instance logs to identify affected systems and technician workstations, review audit logs for RunFiles or RanFiles entries tied to guest processes, and reimage compromised machines from known-good media. Both firms released indicators of compromise and urge disabling those extensions in on-premises ScreenConnect deployments.