Attackers Hijack ScreenConnect at MSPs as ConnectWise Cuts Extensions

Huntress says attackers abused ScreenConnect Run Command at MSPs to push rogue clients and the SCKit toolkit; ConnectWise disabled five extensions at partners.
Table of Contents
    Add a header to begin generating the table of contents

    Attackers are hijacking cloud-hosted ConnectWise ScreenConnect instances at managed service providers and using them to install rogue ScreenConnect clients on customer endpoints, according to Huntress. ConnectWise responded by disabling five third-party ScreenConnect extensions across about 400 partner environments.

    Huntress Counts Hundreds of Endpoints Across Dozens of Organizations

    Huntress detected the campaign at about 17:47 UTC on November 11. BleepingComputer reported an early count of 6 compromised MSPs and 286 endpoints across 47 organizations. The Hacker News later reported at least 288 endpoints across 48 organizations. Huntress said the numbers were still rising, and no attacker has been named.

    How the Rogue Clients Spread

    The attackers used ScreenConnect’s Run Command feature in cloud-hosted instances to install rogue ScreenConnect clients on managed endpoints. Those clients deliver a custom toolkit called SCKit, which gives the attackers persistent remote access. Researchers describe the spread as worm-like, since each compromised MSP can reach many customer networks.

    Sophos X-Ops also found malicious deployments. In those cases, the attackers used curl.exe to fetch a file named ScreenConnect.ClientSetup.msi from their own server. Huntress described custom tooling that is sometimes compiled directly on the victim machine.

    Technician Workstations as a Second Target

    Huntress warned that attackers may also compromise MSP technician workstations. The exposure arises when a technician opens a remote session to an infected customer device, which gives the attackers a path back into the provider’s own environment.

    ConnectWise Disables Five Extensions as a Precaution

    ConnectWise said it disabled five third-party ScreenConnect extensions across about 400 partner environments. The company stated that it has no evidence of a compromise of its own infrastructure and no evidence of a vulnerability in ScreenConnect itself.

    The Extension API Behind the Action

    The extensions expose an API that can execute remote commands, and a passphrase set by the partner protects it. ConnectWise did not describe a specific flaw in that mechanism. On-premises partners were not covered by the cloud action and must disable the extensions themselves.

    ConnectWise shared indicators of compromise, contacted partners and urged them to preserve logs. Huntress cautioned that disabling extensions and resetting credentials may not remove access the attackers have already established on endpoints.

    Initial Access Remains Unexplained at Hijacked MSPs

    Huntress has not identified how the attackers first got into the MSP environments. The company points to compromised credentials or hijacked operator sessions as the likely routes. No vulnerability has been tied to the campaign.

    The distinction matters for the scale of the incident. A software flaw would affect every ScreenConnect customer, while stolen credentials or hijacked sessions limit exposure to providers whose accounts were taken over. ConnectWise’s decision to disable extensions at about 400 partner environments suggests the vendor treats the extension API as a plausible control path, even though it has not found a defect.

    The campaign reflects a familiar pattern in managed service provider attacks, where a single compromised remote management platform gives an attacker access to dozens of downstream organizations at once. Huntress’s updated victim counts on November 12 show the total is still moving, and the company has not said how many of the affected endpoints already run SCKit.

    Huntress and Sophos Findings Point Toward Credential-Based Access

    Huntress first detected the ScreenConnect abuse on November 11, and ConnectWise issued its advisory and disabled the extensions the same day. Updated victim counts followed on November 12. Cybernews and Securityonline also covered the disclosure, and both relay the same core findings from Huntress and ConnectWise.

    The reporting describes a worm-like pattern in which one compromised MSP leads to infected customer endpoints, and those endpoints can in turn expose technician workstations. Each compromised provider can reach many customer networks, and dozens of organizations were affected as of the latest count.

    ConnectWise has told partners it has no evidence of an infrastructure compromise or of a vulnerability in ScreenConnect. Responsibility for the hijacked sessions therefore sits, for now, with the affected provider environments rather than with a product defect. Huntress describes the toolkit as custom and says it is sometimes compiled on the victim machine, which means indicator lists may not cover every build.

    Related Posts