ScreenConnect attacks reach customer endpoints; disabling suspect extensions is only the first step

The counts describe different parts of the incident

Attackers used managed-service providers’ ScreenConnect environments to deploy unauthorized remote-access clients on customer computers. Huntress says it detected malicious commands from cloud-hosted panels at approximately 17:47 UTC on November 11, with its observed impact reaching 288 endpoints across 48 protected organizations within 90 minutes. BleepingComputer’s earlier figures of six compromised MSPs, 286 endpoints and 47 organizations belong to the same developing investigation, not an additional victim population. [1][2]

ConnectWise’s advisory, published November 11 and updated at 02:45 UTC on November 12, described approximately 400 partner environments with suspect extensions installed. That is an installation count, not a count of confirmed compromises. Neither figure establishes global impact. The distinction matters for MSPs and their customers: an extension installation warrants action, while confirmed malicious execution requires investigation of the affected computers as well as the administration environment. [2][3][5]

RMM+ analysis narrows the suspected entry route

In its update at 04:34 UTC on November 12, Huntress implicated RMM+ versions 1.0.31 and 1.0.32. It reported that when administrators had not configured an access key, the extension accepted a blank one, outside ordinary account and MFA controls. Investigated commands were associated with RMM+ without corresponding logins. This is Huntress’s assessment of the entry mechanism, not a root cause confirmed by ConnectWise or proof that every affected environment was entered the same way. [2][3]

Earlier reporting carried hypotheses involving stolen credentials or hijacked operator sessions. The extension analysis is more specific, but the investigation remains open. ConnectWise says it has found no evidence of compromised company infrastructure or a vulnerability in ScreenConnect itself. Huntress identified affected deployments running ScreenConnect 26.6.6.9747 and 26.7.6.9783; observing those builds in incidents does not establish a vulnerability in either build. [2][3][6]

Sophos independently observed malicious deployments

Sophos separately observed an installer downloaded with curl.exe into Windows Temp and silently installed through msiexec.exe, followed by staged scripts and PowerShell retrieval of another payload. Activity originated from three ScreenConnect instance identifiers that Sophos assessed as likely compromised. These endpoint observations independently support the finding that malicious deployments occurred. They do not independently validate Huntress’s full victim count. [4]

Huntress’s customer guidance describes a second attacker-controlled client, a PowerShell toolkit, SYSTEM-level scheduled-task persistence and a modified client impersonating the legitimate installation. Its research and support guidance come from the same publisher, so they are complementary evidence, not independent corroboration. Likewise, BleepingComputer and The Hacker News report Huntress’s findings and comments; their repetition of incident figures does not create separate victim datasets. [1][2][5][6]

Propagation capability is not demonstrated propagation

SCKit’s recovered code aims to move from an infected customer endpoint to a connecting technician, steal session cookies and reach additional endpoints. Huntress has not observed a successful endpoint-to-technician transfer or an onward jump, and console-takeover attempts failed in the recovered logs it checked. The evidence therefore supports malicious endpoint installation and an attempted propagation design, not proven autonomous spread. That limit should remain explicit even while defenders take precautions against the capability. [2][5]

Disable the named extensions and preserve records

ConnectWise directs operators to disable and verify five extensions: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. The company disabled them wherever it could, but on-premises operators must act themselves. Administrators should not reinstall or re-enable them pending further guidance. The vendor’s intervention should not be treated as confirmation that every partner environment has been secured. [3]

Preserve authentication, extension-installation, administrative, Run Command and Toolbox records before cleanup. ConnectWise says it lacks visibility into post-entry activity inside partner environments, making local evidence important to determining what happened after access was gained. Our inference from the vendor advisory and Huntress’s persistence findings is that entry-route containment and endpoint recovery must be tracked separately: disabling an extension or resetting credentials cannot establish that attacker software has been removed. [3][5]

Investigate endpoints without interactive ScreenConnect sessions

Huntress warns against investigating suspected hosts through interactive ScreenConnect sessions, including connections through a new or trial instance. Use separate security tooling, and investigate technician workstations that already connected to affected computers. This is precautionary guidance prompted by the toolkit’s design, not evidence that a technician was successfully infected. Endpoint isolation can block communication, but Huntress says it does not remove the installed components. [2][5]

Useful host indicators include the TrapWatch scheduled task, C:\ProgramData\RelayTrap\ and C:\Windows\Temp\sckit-*. Sophos identifies rogue client identifiers 2588ef5c15954b10 and ed630cc2c873b091. It also recommends examining unexpected client deployments and sequences involving curl or PowerShell downloads followed by installer execution. Behavior-based investigation complements these indicators; Huntress customers should follow their individual incident reports rather than treat a generic checklist as complete remediation. [4][5]

Credential recovery is another distinct task. Huntress advises revoking sessions, resetting passwords, enforcing MFA, removing unknown users and rotating credentials stored or used on affected hosts, prioritizing privileged infrastructure accounts. Those measures address potential continued access through accounts and secrets, while removal of unauthorized clients and persistence addresses access already established on the computer. Neither should be substituted for the other. [5]

Watch for root-cause confirmation and recovery guidance

The next material developments are a vendor-confirmed entry mechanism, a clearer account of total scope and updated guidance on when the disabled extensions can safely return. Any claim of successful self-propagation needs evidence beyond the recovered code’s intended behavior. For now, the strongest shared finding across Huntress and Sophos is unauthorized deployment on customer endpoints. Our assessment is that recovery decisions should rest on investigation of those endpoints and their credentials, not solely on the status of extensions in the management panel. [2][3][4][5]