Attackers have broken into the cloud-hosted ScreenConnect environments of at least six managed service providers (MSPs) and used them to plant rogue remote-access software on customer machines, in an active campaign that began on Wednesday 11 November 2026.

Cybersecurity firm Huntress, which first spotted the activity, says it has identified six compromised MSPs and 286 affected endpoints across 47 organisations — and that the numbers were still rising when it raised the alarm. ConnectWise, the company behind ScreenConnect, has confirmed it is investigating and has disabled five third-party extensions across around 400 partner environments as a precaution.

How the campaign works

ScreenConnect is a remote-access and support platform that MSPs and IT teams use to manage and fix customer devices from afar. That reach is exactly what makes a hijacked console so dangerous: whoever controls it can reach every device the MSP manages.

Huntress says its security operations centre first saw the activity at around 17:47 UTC on Wednesday, targeting cloud-hosted ScreenConnect instances. The attackers are using ScreenConnect's own Run Command feature to install additional ScreenConnect clients on managed endpoints, giving themselves remote access that sits outside the legitimate MSP's ScreenConnect environment.

How the attackers are getting into the MSP environments in the first place has not yet been established. Huntress says its current telemetry points to compromised credentials and hijacked MSP support sessions, and it has not tied the campaign to a software vulnerability. Nobody has confirmed whether the initial access relies on a flaw in ScreenConnect itself or on abuse of legitimate features.

Huntress also warned of a potentially more dangerous technique: attackers may be able to compromise an MSP technician's workstation when the technician starts a ScreenConnect session with an infected customer device. How that reverse-pivot would work — including whether it exploits a software vulnerability or abuses legitimate functionality — is still unclear, and should be treated as a credible warning rather than a confirmed exploit.

ConnectWise responds

In a statement to BleepingComputer, ConnectWise said it was aware of reports of malicious activity affecting a limited number of ScreenConnect partners and was actively investigating. It urged partners to avoid opening interactive ScreenConnect sessions to suspected compromised devices and to use separate security tools to investigate, review account activity, revoke active sessions, reset credentials from a trusted device and verify multi-factor authentication.

ConnectWise also posted an advisory to its Trust Center and disabled five third-party extensions as a precaution: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. The company's early theory points to third-party ScreenConnect extensions rather than a confirmed flaw in the core product, but the root cause has not been established.

Huntress has shared indicators of compromise to help organisations search for the activity, including an attacker relay at 185.99.255.28 and rogue ScreenConnect client IDs 2588ef5c15954b10 and ed630cc2c873b091. It also warned that sequential identifiers used by the attackers suggest additional MSPs may have been compromised earlier than Wednesday, and urged ScreenConnect users to check their Run Command history even if they have not received alerts.

A familiar target

ScreenConnect has been a prime target for attackers before. In February 2024, two critical flaws in the product — CVE-2024-1709, an authentication bypass, and CVE-2024-1708, a path traversal flaw — were exploited within hours of disclosure, and ransomware groups including Bl00dy and Black Basta used them to push ransomware into the customers of affected MSPs.

The November campaign is different in shape: rather than a single vulnerability being exploited at scale, attackers appear to be working through compromised MSP accounts and sessions, then abusing the platform's own management features. That makes the defence less about a single patch and more about the basics — strong, unique credentials, multi-factor authentication on every technician account, and close monitoring of Run Command activity and session history.

BleepingComputer also found an earlier malicious batch script referencing one of the rogue client IDs, first uploaded to VirusTotal on 25 July 2026, which suggests the identifier was used in malicious activity months before the current attacks were disclosed. Whether the July activity and the current MSP campaign are part of the same operation remains unclear.

For MSPs, the immediate advice is to review environments for signs of compromise, avoid interactive sessions with potentially infected endpoints, and check Run Command history now — not after an alert arrives.

Sources: BleepingComputer and QUE.com.