On November 11, 2026, attackers who had gained control of cloud-hosted ConnectWise ScreenConnect panels used the platform's own Run Command feature to push rogue ScreenConnect clients, and a custom toolkit called SCKit, onto managed endpoints. Huntress has counted at least 288 hosts across 48 organizations in its own telemetry, and all of them were hit within roughly 90 minutes. ConnectWise has disabled five third-party extensions in about 400 partner environments as a precaution and says it has found no evidence of a ScreenConnect vulnerability or a compromise of its own infrastructure. 

For industrial operators this is not an "IT-only" story. The same pattern (a trusted service provider's remote-management console becoming a distribution channel for an attacker's own remote-access tool) is the threat model behind OEM, integrator and MSP access to plants, substations and treatment sites. Nothing published so far shows this campaign reaching a control network. The exposure path, however, is real, and this article separates what is confirmed from what is merely possible. 

Executive Summary: What Happened? 

• Date and discovery: Huntress's SOC saw malicious activity from about 17:47 UTC on November 11, 2026. ConnectWise published an advisory at 22:45 UTC the same day. 

• Mechanism: Run Command was used to execute commands as SYSTEM, install an attacker-controlled ScreenConnect client and deploy SCKit, which adds Defender exclusions, creates a TrapWatch scheduled task and displaces the legitimate ScreenConnect client. 

• Scale (Huntress telemetry): at least 288 endpoints, 48 organizations. Initial reporting said 286+ endpoints, 47 organizations and six compromised MSPs. 

• Root cause: not established. ConnectWise's initial assessment points to abuse of independent third-party extensions. Huntress has linked the activity to RMM+ versions 1.0.31 and 1.0.32, which accepted a blank access key if none was configured. Huntress's telemetry had also pointed to compromised credentials or hijacked operator sessions. 

• Attribution: none. No vendor or researcher has named an actor. 

• Key implication: disabling the extensions or resetting passwords does not remove rogue clients already installed on endpoints. 

Inside the Attack: Why ScreenConnect and Its Extensions Matter 

ScreenConnect is a remote support and access platform widely used by MSPs to administer customer endpoints. A single panel can reach hundreds of machines across many customers, and its Run Command and Shared Toolbox features can execute scripts on every session a user may reach. That reach is the product's value and, in this incident, the attacker's leverage. 

ScreenConnect also supports third-party extensions installed through its marketplace. ConnectWise says the five extensions it disabled (Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link) come from independent developers and expose an API capable of executing remote commands, protected by a passphrase the partner sets during configuration. ConnectWise does not accuse the developers of wrongdoing. Some outlets list only four of the five names; the vendor and Huntress both list five. 

Incident Timeline (UTC) 

Exact publication times for Huntress's post and the Reddit alert are not stated in the sources reviewed. This article does not record a minute-level research cutoff. 

How the Attack Happened: A Technical Reconstruction 

Panel access (method unconfirmed: RMM+ blank-key API, stolen credentials or hijacked sessions) 
  -> Run Command broadcast to groups of managed endpoints, as SYSTEM 
  -> curl downloads attacker ScreenConnect MSI to C:\Windows\TEMP\sc.msi; silent msiexec install 
  -> base64 dropper written to C:\Windows\Temp\sckit-run.bat 
  -> sckit-decoder.ps1 fetched; keyed SCKit package downloaded per host 
  -> RelayTrap + TrapWatch task + Defender exclusions + second rogue client 
  -> legitimate ScreenConnect client stopped and displaced 
  [Designed, not observed to succeed] technician session -> cookie theft -> Shared Toolbox broadcast 

Initial access. Huntress told press it has not seen evidence of a new vulnerability and that how the operator reached the panels remains unclear; telemetry pointed to compromised credentials or hijacked operator sessions. ConnectWise says initial access and full scope remain under investigation. The RMM+ finding offers a mechanism that would explain Run Command activity without conventional logins, but whether it accounts for all victims is not established. 

Execution. Huntress reports the operator used Run Command to send the same command set to many endpoints at once. The command checked for an existing client, downloaded the attacker's installer from the attacker relay and installed it silently. Sophos independently observed the same pattern: curl pulling the MSI, a ScreenConnect-generated command file launching msiexec, batch staging, and PowerShell with execution-policy bypass fetching a second stage. 

Abuse versus exploitation. Run Command is an authorized administrative capability. Using it after gaining panel access is abuse of legitimate functionality, not exploitation of a ScreenConnect software bug. The only authentication weakness identified so far sits in a third-party extension (section 5). 

Why rogue clients are hard to spot. The payload is a genuine ScreenConnect client, signed and behaviorally identical to the MSP's own agents. Environments already running ScreenConnect expect its processes, services and traffic. The discriminator is the instance identifier, and the observed installer URLs carry an &c=Exploited<N> pattern with a participant named Addmin. 

The RMM+ Extension Weakness: What Researchers Found 

Huntress describes RMM+ as a third-party extension that lets another tool manage ScreenConnect sessions without a technician working through the console. Its key properties: 

• It bypasses ScreenConnect user accounts, roles and MFA and instead authenticates API requests with a shared access key stored in the extension's settings. 

• In versions 1.0.31 and 1.0.32 the key defaulted to blank, and the check did not reject an empty value, so a caller could pass authentication where an administrator never set a key. 

• The extension's own configuration text tells administrators to set a strong key. 

• A secondary outlet citing Huntress reports that commands in reviewed logs were associated with RMM+ without matching login activity; treat that as reported, not independently verified here. 

There is an apparent tension: ConnectWise says the API is secured by a partner-configured passphrase, while Huntress says an unconfigured passphrase was accepted blank. These statements are compatible. The protection depends entirely on configuration. 

Classification. This is a weakness in a third-party extension's authentication model, not a vulnerability in core ScreenConnect. Huntress says the activity "seems to be related" to RMM+, which is a hedged finding. Huntress's key takeaways also list ScreenConnect builds 26.6.6.9747 and 26.7.6.9783 as affected; the post does not say those builds contain a flaw, and ConnectWise says it has found none. Read these as version context from affected environments. 

Inside SCKit: The Malicious Toolkit 

SCKit is a package of 16 files (PowerShell, batch, .cmd and configuration data). It is delivered encrypted: the host sends its Windows UUID in the request, and the server returns the key, IV and salt in response headers so each kit decrypts only on the intended machine. Huntress therefore calls file hashes weak indicators; scripts are rebuilt with different embedded values and the trap executable is compiled per host. Huntress also assesses that the RelayTrap C# source appears LLM-generated, based on its detailed comments. 

Huntress also notes the toolkit adds SRP/AppLocker rules intended to block files pushed through ScreenConnect's temp folders, and ships cleanup scripts. It uses sqlite3.exe, fetched from the stager, to read browser cookie databases. 

Lateral Movement and Technician Session Exposure 

The practical conclusion is conservative: treat any technician workstation that connected to a suspect host as potentially exposed, but do not describe cross-customer spread as confirmed. This is why Huntress warns against connecting to suspected hosts through ScreenConnect at all. 

Who Is Behind the Attack? 

Attribution is unconfirmed. ConnectWise has not named an actor and Huntress has not published one. Motivation cannot be established from the evidence: the toolkit supports persistent access and session theft, which is consistent with several objectives, none demonstrated. 

A few clues exist, but none proves identity: the participant name Addmin, sequential per-MSP tags (starting partway through the sequence, suggesting earlier victims), skip lists that exclude the attacker's own machines, and likely LLM-assisted code. BleepingComputer also reported an earlier malware sample sharing one rogue client ID, with Telegram-based success notification and ScreenConnect MSI downloads from the same cdn007-digitaldownloads domain Huntress lists, which suggests prior use of this infrastructure; whether it is the same operator is not established. 

Two unrelated precedents should not be conflated with this event. Sophos documented a Qilin-affiliate cluster (STAC4365) that phished an MSP's ScreenConnect administrator in early 2025, and ConnectWise attributed its October 2026 Cloud Backup incident to a China state-aligned group. Neither source links these to November 11. Higher-confidence attribution would need panel and extension access logs, initial-access evidence from affected MSPs, infrastructure registration and hosting overlaps, and independent code and tooling comparison. 

Scale: MSPs, Endpoints and Downstream Exposure 

The 288 figure reflects only Huntress's visibility and is not the global total. Sequential tags imply earlier compromises. The working headline's "47 organizations" is outdated; this article uses 48. 

What Was the Actual Damage? 

Confirmed: unauthorized persistent remote access on at least 288 endpoints; Defender exclusions and displaced legitimate clients on affected hosts; reinfection after isolation was lifted. 

Not confirmed in the sources reviewed: data exfiltration, credential theft, successful session hijacking, ransomware deployment, access to internal customer systems beyond the endpoints, financial losses, regulatory consequences, or any operational or industrial disruption. Remote access alone does not prove exfiltration. Treat the absence of reports as unknown rather than reassuring, since investigations are ongoing.  

Indicators of Compromise and Defensive Investigation 

Values below are defanged. A match must be investigated in context; no single indicator establishes compromise. 

Huntress publishes SHA256 values for the scripts but warns they are weak indicators. BleepingComputer additionally reported amexsafekeyupdate[.]com and cyberrexdesign.screenconnect[.]com in a related earlier sample; relationship unconfirmed. 

Why This Incident Matters Beyond MSPs 

The incident shows three supply-chain failures at once. First, an integration (an extension) can carry its own authentication model that sits outside the platform's MFA and role controls. Second, the privilege that makes remote management efficient, mass execution as SYSTEM, makes a compromised panel a one-step distribution system. Third, the customer cannot easily tell a second legitimate-looking ScreenConnect client from the first. Defenders must treat their service providers' tooling as part of their own attack surface. 

The OT Cybersecurity Connection: A Potential Entry Point into Industrial Environments 

Evidence versus hypothesis. No source reviewed reports this campaign reaching an industrial control network, and no OT impact is confirmed. What follows is exposure analysis. 

Industrial operators depend on OEMs, system integrators, engineering contractors, maintenance providers, MSPs and MSSPs, many of whom use general-purpose remote tools from laptops that also touch customer IT estates. A compromised provider console or technician workstation inherits those trusted paths. 

A realistic, hypothetical pathway: 

Compromised MSP identity or extension -> MSP remote-management panel 
  -> rogue client on customer IT endpoint or technician workstation 
  -> customer IT/enterprise network 
  -> weakly controlled IT/OT boundary (shared credentials, flat routes, standing VPN) 
  -> OT DMZ, jump server or engineering workstation -> HMI / SCADA / historian / PLC engineering tools 

Every step after the rogue client is conditional on the operator's architecture, which is the point: the controls below determine whether this path exists. 

Why trust is the weakness. Remote access should not be trusted because it comes from an approved vendor, an authorized MSP, a known product or a previously approved account. Recurring failure modes include persistent always-on vendor VPNs, shared accounts, unrestricted jump-server access, excessive privilege, weak or non-phishing-resistant MFA, no session recording, no asset-level restriction, flat IT/OT segmentation, stale vendor accounts after offboarding, and unmonitored third-party tools. 

Recommended OT remote-access architecture. 

1. Dedicated OT remote-access path terminating in an industrial DMZ, separate from enterprise remote-management tooling; no vendor tool installed directly on OT assets. 

2. Segmentation by zones and conduits, with deny-by-default firewalling and no direct routes from enterprise IT to Level 2 and below. 

3. Brokered jump-server access with per-asset, per-protocol allow-lists. 

4. PAM with just-in-time, time-boxed sessions and explicit approval for each maintenance window, including emergency break-glass with after-the-fact review. 

5. Named per-person, per-vendor identities with phishing-resistant MFA (FIDO2/passkeys); no shared accounts. 

6. Session recording and live supervision, with the ability to terminate sessions. 

7. Application allow-listing on jump hosts and engineering workstations; restricted access to engineering software. 

8. Passive, continuous monitoring of remote-access activity, with logs centralized in a SIEM and alerting on unapproved remote-access software. 

9. Regular third-party access reviews, prompt revocation and verified offboarding. 

10. Independent validation of vendor tools and extensions before they touch your environment, plus contract clauses requiring notification of provider compromise. 

These controls reduce blast radius: a compromised MSP panel can reach only what a time-limited, approved, recorded, allow-listed session permits, and cannot reach OT without a separate, human-approved path. Do not actively scan or test production control systems without an OT-led authorization; use passive monitoring and controlled lab validation. 

Immediate Mitigation and Incident Response 

First 0–4 hours 

• Read the ConnectWise advisory. Confirm the five extensions are disabled; on-premises partners must do this themselves, as ConnectWise cannot. 

• Check whether RMM+ 1.0.31/1.0.32 was installed and whether an access key was ever set. 

• Audit Run Command and Toolbox history for mass or unfamiliar executions; look for unknown ScreenConnect client services and the two rogue client IDs. 

• Do not connect to suspect hosts through ScreenConnect. An interactive session may trigger the designed technician-side spread. Use EDR live response, WinRM or another out-of-band method from a clean device. 

• Isolate suspect hosts, preserving evidence first. 

First 24 hours 

• From a clean device, terminate active ScreenConnect sessions, rotate ScreenConnect and identity-provider credentials and revoke browser and token sessions. 

• Enforce MFA, audit administrator roles and new accounts, review identity-provider sign-ins and instance audit logs. 

• Examine technician workstations that connected to suspect hosts; remove TrapWatch, RelayTrap directory and the Run value; verify the legitimate client separately. 

• Block verified infrastructure. Disabling extensions or resetting passwords does not remove installed persistence. 

First 72 hours 

• Complete scoping across endpoints and servers, including domain controllers and other privileged systems, and assess credential exposure. 

• Notify downstream customers; assess contractual and regulatory notification duties. 

• Preserve logs, document decisions, and validate that hosts are clean before reconnecting (reinfection was seen after isolation ended). 

Longer term: govern third-party access, review every extension, enforce strong secrets, harden remote access (allow-listed source IPs, SSO with MFA), deploy EDR/NDR and SIEM coverage of ScreenConnect logs, segment OT, review vendor access periodically, and rehearse supply-chain incident response. 

Detection Engineering 

The following are illustrative starting points, untested and not production-ready; tune to your telemetry. 

• Panel: many sessions receiving a Run Command from one actor within minutes; Toolbox items created and deleted within about 60 seconds; extension API activity with no corresponding login; new administrators or extension installs. 

• Endpoint: curl.exe writing C:\Windows\TEMP\sc.msi followed by msiexec; PowerShell with execution-policy bypass fetching from unfamiliar hosts; files named sckit-* in C:\Windows\Temp; creation of a TrapWatch task; new Run-key value RelayTrapLiteAlert; new ScreenConnect Client (<instance id>) services whose ID is not in your allow-list; Defender exclusion changes; SRP/AppLocker rule changes. 

• Network: connections to the listed IPs and domains; ScreenConnect relay traffic to instance IDs you do not own. 

// pseudocode, untested 
services WHERE name LIKE "ScreenConnect Client (*)" 
  AND instance_id NOT IN approved_instance_ids 
UNION scheduled_tasks WHERE name = "TrapWatch" 
UNION registry WHERE path ENDS "\Run" AND value = "RelayTrapLiteAlert" 

In OT networks, rely on passive monitoring at the DMZ and span ports, and validate detections in a lab rather than on live controllers. 

MITRE ATT&CK Mapping 

The IDs below are mapped from knowledge of the framework and should be re-verified against attack.mitre.org before publication. 

Standards and Regulatory Considerations 

Clause-level references below should be confirmed against your licensed editions before you rely on them. 

• NIST SP 800-82 Rev. 3 (September 2023) is the current final OT security guide, with an OT overlay for SP 800-53 Rev. 5; a Rev. 4 draft is reportedly open for comment. It addresses remote access, segmentation and vendor access. 

• IEC 62443: zones and conduits (62443-3-2), system security requirements for access control and authentication (62443-3-3), and service-provider security requirements (62443-2-4) bear directly on third-party maintenance. 

• NIST CSF 2.0: the Govern function's supply-chain risk management category applies to provider oversight. 

• NERC CIP (where applicable): CIP-005 interactive remote access and vendor remote access controls, and CIP-013 supply-chain risk management. 

• NIS2 (EU): Article 21 requires supply-chain security among its risk-management measures. 

The common principles: authenticate strongly, restrict and record third-party sessions, segment by zone, monitor, and test your response. 

Frequently Asked Questions 

Is ScreenConnect itself vulnerable? ConnectWise says it has no evidence of a ScreenConnect vulnerability or infrastructure compromise. A weakness exists in a third-party extension, RMM+ 1.0.31/1.0.32. 

How many organizations are affected? At least 48 in Huntress's telemetry as of November 12, 2026. About 400 partner environments had flagged extensions, which is an exposure count. 

Who is responsible? Unknown. 

Does resetting passwords fix it? No. Rogue clients and persistence must be removed from endpoints. 

Are industrial systems affected? No OT impact has been reported. The risk is the access pathway. 

Conclusion

The lesson for OT leaders is architectural: no remote-management platform, however trusted, should be able to reach industrial assets through a standing, unrecorded path. Verify extensions, segment, broker and record every third-party session, and monitor passively. 

Additional resources:

NERC CIP-015 Internal Network Security Monitoring Readiness Checklist for Electric Utilities here
OT SOC Foundational Guide here
Managed SOC Service here
OT Cyber Threat Intelligence Advisory - Middle East here
NIS2 Directive Achieving NIS2 Compliance Through IEC 62443 here
What Is Removable Media? Risks, Policies, and Industrial OT Security Solutions here
Free Removable Media Policy Template for OT and IT Teams here