-14.png?w=1024)
A compromised remote-support console can give attackers a route into multiple customers’ devices—and leave unauthorized access behind after the console is secured.
Huntress is investigating attacks that used cloud-hosted ConnectWise ScreenConnect panels to install rogue remote-access clients and a toolkit called SCKit. The company reported at least 288 affected endpoints across 48 organizations in its customer base following activity detected Nov. 11.
For managed service providers (MSPs), the immediate task extends beyond securing administrator accounts: customer endpoints need investigation, and technicians should avoid interactive ScreenConnect sessions with suspected infected devices.
Attackers used remote-support commands to deploy rogue clients
In its technical analysis, Huntress said an operator used ScreenConnect’s Run Command feature to push commands to multiple endpoints with SYSTEM privileges. All 288 observed hosts were affected within 90 minutes, roughly a third within the first 10 minutes.
The commands installed attacker-controlled ScreenConnect clients and SCKit. Researchers also identified a scheduled task called TrapWatch and a toolkit directory at C:\ProgramData\RelayTrap\.
Huntress found code intended to spread from an infected endpoint to a technician’s workstation, then to additional endpoints accessible through the technician’s ScreenConnect session. However, it had not observed either jump succeed; console-takeover attempts failed in every recovered host log it examined.
That distinction matters: deployment across customer endpoints was observed, while successful automatic propagation through technicians was not established.
The misuse of legitimate remote-access software has also appeared in a fake Clawdbot VS Code extension. Similar DocuSign-themed phishing attacks delivered legitimate remote-management tools to Windows and macOS users. A familiar product name cannot establish that an installation is authorized.
ConnectWise disables five third-party extensions
ConnectWise’s Nov. 12 advisory update said its initial assessment pointed to possible abuse of independent third-party extensions. The initial access method and full scope remained under investigation, and the company reported no evidence of compromised ConnectWise infrastructure or a vulnerability in ScreenConnect itself.
The five extensions identified for precautionary disabling are:
- Labtech Plus
- RMM Plus
- RMM+
- RMM Plus Password Link
- RMM+ Password Link
ConnectWise identified approximately 400 partner environments with at least one listed extension and disabled the extensions wherever it could act. On-premises partners must disable them themselves and should not reinstall or re-enable them pending further guidance.
The company said the extensions provide a remote-command API protected by a partner-configured passphrase. Investigators have not confirmed whether that API was the entry point. The approximately 400 environments contained the extensions; they were not all confirmed compromised and should be counted separately from Huntress’s affected endpoints and organizations.
Investigate endpoints before restoring remote access
Huntress’s incident-response instructions warn affected customers not to connect to infected hosts through any ScreenConnect instance, including a new or trial instance. Isolation blocks attacker access but does not remove the toolkit.
Huntress recommends using endpoint detection and response (EDR) live response or another out-of-band command-line tool to investigate. Technician workstations that connected to suspected infected hosts should also be assessed.
For responders, the work should cover three areas:
Area | What to establish |
|---|---|
| Management access | Which accounts, sessions, and commands were involved, and which customer systems they could reach. |
| Customer endpoints | Whether additional remote-access clients or persistence remain after containment. |
| Technician workstations | Whether staff connected to suspected infected devices and whether their systems or sessions may be exposed. |
ConnectWise recommends using separate security tooling, preserving logs, revoking ScreenConnect and associated identity-provider sessions, resetting credentials from a trusted device, and enforcing multifactor authentication.
Build the investigation around both management records and endpoint evidence. Run Command history can help identify the deployment window; endpoint telemetry can show which installations followed. Compare those findings with approved maintenance work rather than treating every ScreenConnect service as malicious.
The wider abuse of RMM tools across phishing campaigns reinforces the need to document approved remote-access products and their owners. During this incident, that inventory gives responders a baseline for identifying unexpected clients.
Businesses using an MSP should request a clear account of which management environments were reviewed, whether their devices received unauthorized software, and how the provider validated cleanup. Confirmation that an extension was disabled answers only part of that inquiry.
Before restoring routine support, document who approves reconnection and require evidence that:
- Relevant logs and endpoint evidence were preserved before cleanup.
- Unauthorized remote-access clients and persistence mechanisms were removed.
- Potentially exposed sessions were revoked and affected credentials reset.
- Follow-up checks found no reinfection.
Password resets, extension disabling, and endpoint cleanup address different parts of the intrusion. Continue monitoring both management activity and endpoints, and follow vendor updates as investigators establish the access path and scope.
Read more: How attackers hide credential theft and ScreenConnect installations behind trusted Google links explains another route by which unauthorized remote access can reach employee devices.