An active campaign is using cloud-hosted ScreenConnect instances to push attacker-controlled remote access clients onto the machines that managed service providers support. Huntress opened the investigation on 11 November and ConnectWise has confirmed it is engaged.
What happened
Attackers are abusing ScreenConnect's Run Command function to deploy a second ScreenConnect client on managed endpoints. That client sits outside the legitimate provider's tenant, so the sessions it opens never appear in the provider's own console.
Huntress reported six compromised MSPs, 286 affected endpoints and 47 impacted organisations at the time of disclosure, and said the count was still climbing. The firm had not yet established how attackers got into the affected environments, but its telemetry points to compromised credentials and hijacked support sessions. Sequential tags assigned by the attackers suggest earlier intrusions at other providers.
A second technique worries responders more: a technician who starts an interactive session with an already-infected customer device may hand over their own workstation. Huntress has not said whether that reverse pivot relies on a software flaw or on legitimate product behaviour.
Who is affected
Any organisation that uses ScreenConnect, or whose IT provider uses it to manage their estate, is in scope until the campaign is contained.
- Managed service providers running cloud-hosted ScreenConnect, including six confirmed compromises
- Customer endpoints that received unattended sessions or commands from those instances
- Technician workstations used to open interactive sessions to customer devices
- Any provider whose Run Command history shows commands it did not issue
What to do now
Do not open interactive ScreenConnect sessions to a device you suspect is compromised. Investigate it with separate tooling, and audit Run Command history across every tenant.
- Review Run Command history and session logs for commands and client installs nobody on the team issued, including before this week
- Revoke active sessions and reset credentials from a known-clean device, not from a workstation that may already be compromised
- Confirm MFA is enforced on every ScreenConnect account, including service and integration accounts
- Hunt for unexpected ScreenConnect client installations and for outbound connections to unfamiliar relay infrastructure
- Treat affected customer devices as compromised hosts, not as a support-tool misconfiguration
What this means for South African businesses
Remote management tooling is the highest-value target in an MSP estate, because a single compromised technician account reaches every client at once. A South African provider with 40 customers does not have 40 incidents to work through after an event like this; it has one blast radius covering all 40, including the backups and the email tenants.
Smaller providers are the likeliest to be exposed, because tooling is often deployed once and never re-audited: old technician accounts stay active, MFA is skipped for convenience accounts, and nobody has ever read a Run Command log. If your provider cannot show you which sessions touched your servers last week, that is the question to ask them today.
Source
Details in this post are from BleepingComputer's report on the ScreenConnect campaign, which includes ConnectWise's guidance to partners.
Also on the blog
- NightsBridge breach: guesthouse booking data is now fueling deposit fraud
- ASUS router CVE-2026-88710: CVSS 8.7 root access from the local network
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.