ScreenConnect Attack Targets MSPs: Rogue Clients Backdoor Customer Devices

The attackers do not appear to need novel malware for this. They are using the remote-access tool that MSPs rely on to support their customers.

What Huntress found​

Huntress posted its first warning to Reddit, and BleepingComputer then reported it. Huntress reported that the campaign began around 17:47 UTC Wednesday and targeted cloud-hosted ScreenConnect instances. The attack moved quickly. Within a few hours of that start time, the firm was counting victims in the dozens of organizations.

Here is how it works, according to Huntress:

• Initial access is unconfirmed. Huntress has not yet determined how the attackers are gaining access to affected MSP environments, but says their current telemetry points to compromised credentials and hijacked MSP support sessions.
• Run Command pushes out a second ScreenConnect client. According to Huntress, attackers are using ScreenConnect's Run Command functionality to deploy ScreenConnect clients on managed endpoints, providing remote access outside of the legitimate MSP's ScreenConnect environment.
• The second client is a separate backdoor. QUE.com's analysis points out that those clients report to infrastructure the attackers control, giving them a separate remote-access channel that sits outside the legitimate MSP's own environment and survives even if the MSP's account is cleaned up.

That last point is the important one. Resetting a stolen MSP password does not remove a rogue client that has already been installed on hundreds of customer PCs. Each infected endpoint stays open to the attacker until someone finds the client and removes it.

Section summary: The attackers allegedly used legitimate ScreenConnect administration features, after gaining access to MSP environments, to plant their own ScreenConnect clients on customer machines. Credential resets alone do not remove those clients.

The "reverse pivot" warning​

Huntress also flagged a more troubling possibility. 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.

Normally, the technician's machine controls the remote session. In this scenario, an infected customer device could compromise the technician's machine instead. If that works, attackers could reach other customers through the infected technician's workstation.

BleepingComputer's reporting says it is still unclear how this technique works. Nobody has said whether it relies on a software vulnerability or on abuse of legitimate ScreenConnect features. Treat it as a credible warning, not a confirmed exploit.

There is useful background here. In late summer, Huntress documented a different campaign in which it used modified ScreenConnect clients to propagate the VBScript chain (specifically executing the four files (1.vbs to 4.vbs) to connected ScreenConnect endpoints, creating worm-like spread across newly connected systems. In ConnectWise's Trust Center bulletin on a guest file-transfer issue in ScreenConnect sessions, tracked as CVE-2026-84869, the company says on-premises ScreenConnect installations should be upgraded to 26.6.5 or later and that cloud deployments were updated automatically.

Nobody has tied the November campaign to that September issue. Help Net Security noted at the time that ConnectWise has not confirmed a link between the file transfer flaw and the rogue ScreenConnect campaign Huntress described. The earlier case does show that ScreenConnect connections have carried malicious code from one machine to another before, which helps explain why researchers took the reverse-pivot risk seriously.

ConnectWise's response and the third-party extension lead​

ConnectWise told BleepingComputer it was aware of malicious activity affecting a "limited number" of ScreenConnect partners and was actively investigating. Its immediate advice to partners:

1. Do not open interactive ScreenConnect sessions to devices that may be compromised.
2. Investigate those devices with separate security tools.
3. Review account activity.
4. Revoke active sessions.
5. Reset credentials from a trusted device.
6. Verify that multifactor authentication is in place.

The ConnectWise Trust Center advisory adds a lead that the early reporting did not have. The company says its initial assessment suggests the attacker deployed additional remote-access software through independent third-party extensions that partners may have added to their ScreenConnect environments. ConnectWise says that assessment, and the reports of technician workstation compromise, still need to be validated.

QUE.com reported that ConnectWise disabled five third-party extensions across about 400 partner environments. The Trust Center tells partners using those extensions to:

• Confirm the extensions are disabled.
• Keep installation records and activity logs.
• Leave the extensions off and not reinstall them until ConnectWise issues further guidance.

ConnectWise also says that partners who have not deployed those extensions have no reason to believe they are affected, but should stay on heightened alert.

ConnectWise's advisory is also clear on two limits: disabling extensions and resetting credentials may not remove access already established on endpoints, and installing updates does not replace investigating a suspected compromise.

Section summary: ConnectWise's early theory points to third-party ScreenConnect extensions, not a confirmed core product flaw, but the root cause has not been established. Its guidance focuses on investigating, preserving evidence and securing admin access from clean devices.

Indicators of compromise​

Huntress shared IOCs to help organizations search for the activity. They are listed below in defanged form, as published. Huntress also shared indicators of compromise (IOCs) to help organizations identify malicious activity, including rogue ScreenConnect client IDs and infrastructure used by the attackers.

The installer pattern deserves attention. Huntress said sequential tags assigned by the attackers, such as the numbered Exploited<N> values, suggest other MSPs may have been compromised before Wednesday. It told BleepingComputer that ScreenConnect users should check their Run Command history even if they have not received any alerts. In other words, MSPs that have not been alerted should still check their logs.

A July sample shares one of the rogue client IDs​

BleepingComputer found an older sample that contains one of the rogue client IDs. BleepingComputer identified an earlier malicious batch script that references one of the rogue ScreenConnect client IDs listed by Huntress, suggesting that the ID was used in malicious activity months before the current attacks were disclosed.

The file, SSA-2026-STATEMENT-15518787.bat, was named to look like a Social Security Administration statement and was first uploaded to VirusTotal on July 25, 2026. According to BleepingComputer's analysis, it:

• Tried to add Microsoft Defender exclusions.
• Set up persistence through the Windows Startup folder and the Run registry key.
• Contacted amexsafekeyupdate.com to fetch installation commands for two installers.
• Was linked in VirusTotal sandbox activity to ScreenConnect MSI downloads from cdn007-digitaldownloads[.]com and cyberrexdesign.screenconnect[.]com.
• Then, after launching the second installer, the script uses PowerShell to search running processes and Windows services for ed630cc2c873b091, one of the rogue ScreenConnect client IDs identified by Huntress. If it found the ID, the script treated the install as successful and notified the attackers via Telegram.

The shared indicator is a real lead, but it does not prove the July activity and the November attacks are one operation. The July file looks built for a phishing campaign aimed at consumers, not for breaking into MSP consoles. BleepingComputer says explicitly that it is unclear whether the two are part of the same campaign.

What MSPs and IT admins should do now​

This list combines ConnectWise's published guidance, Huntress's recommendations and standard incident-response practice:

1. Don't remote in to investigate. Use your EDR or security provider's response tools on suspected hosts, not an interactive ScreenConnect session.
2. Use a clean device for admin work. Revoke ScreenConnect and identity-provider sessions, reset passwords and confirm MFA is enforced from a machine you trust. If a technician's workstation may be compromised, do not use it.
3. Check your extensions. If you installed third-party ScreenConnect extensions, confirm they are disabled and keep the related logs.
4. Review Run Command and Toolbox history for commands you don't recognize, especially MSI installs matching the &c=Exploited<N> pattern.
5. Hunt for rogue clients. Search endpoints for ScreenConnect services or processes containing the two rogue client IDs, and for network connections to the listed infrastructure.
6. Look for Defender tampering. Unexpected Microsoft Defender exclusions and new Run-key or Startup-folder entries were part of the July sample's behavior and are worth checking across the fleet.
7. Isolate first, then clean up. Preserve evidence before removing anything, and confirm the cleanup worked before reconnecting. In the earlier worm-like campaign, for confirmed compromises, Huntress recommends reimaging affected hosts from known-good media.
8. Check versions. Make sure on-premises servers are at 26.6.5 or later, and that technician clients and endpoint agents are current. Remember that patching does not undo a compromise.

Analysis: an old problem, getting worse​

This is the latest example of a problem the industry has seen for years: an attacker who gets into one RMM console can reach many customer networks at once. Huntress says RMM abuse is one of the top attack vectors it has seen over the past year, and this year alone ScreenConnect has been at the center of worm-like rogue-client spread and Power BI–hosted phishing lures.

Two caveats are worth keeping in mind. First, ConnectWise calls the impact "limited," while Huntress says the victim count is climbing. Both can be true on the same day, and neither figure is final. Second, there is no CVE and no confirmed vulnerable version for this campaign. ScreenConnect admins should be urgent but not panicked. Compromised credentials and riskier third-party add-ons may matter as much as any bug.

What should MSPs take from this? Review every ScreenConnect extension you've installed, decide whether you still need it, and remove what you don't.