For MSPs, remote management software is supposed to provide controlled, trusted access to customer systems. But new research from Huntress shows how attackers are turning that trust against defenders.
Researchers identified rogue ConnectWise ScreenConnect clients that can deliver and execute a four-stage VBScript attack chain on newly connected Windows systems. More concerning, compromised clients can automatically push those scripts to other ScreenConnect hosts, creating what Huntress describes as worm-like behavior. Read the Huntress investigation.
That matters because this is not simply another malicious attachment or unknown executable. The attacker is abusing legitimate remote-management functionality and familiar Windows components to carry out the attack.
Key Takeaway: Trusted software does not automatically mean trusted behavior. When attackers can abuse legitimate RMM tools, scripts, PowerShell, and Windows functionality, organizations need controls that restrict what those applications are allowed to do, not just controls designed to identify malicious files.
Huntress investigated multiple unrelated incidents in August involving rogue ScreenConnect installations. Initial access varied, including a Quick Assist technical-support scam, a likely phishing-delivered ScreenConnect installer, and a fake Geek Squad refund lure.
Once installed, the rogue ScreenConnect clients repeatedly launched Windows Script Host, wscript.exe, to execute four VBScript files.
The scripts progressively profiled the endpoint, checked installed security products, downloaded additional payload information, retrieved encrypted payloads, and ultimately launched PowerShell to decrypt and execute additional code.
The final payload depended on what the scripts discovered about the machine. Huntress observed branches involving persistent ScreenConnect backdoors, privilege escalation, tunneling tools, attempts to weaken Microsoft Defender protections, and an XMRig cryptocurrency miner. See the technical details from Huntress.
Because a compromised endpoint can become a delivery mechanism for attacks against other systems.
According to Huntress, the modified ScreenConnect client watches for newly established Host sessions. When another system connects, the malicious client can register the four VBScript files with ScreenConnect's file-transfer functionality and cause them to execute on the connected host.
That creates a potentially dangerous trust relationship.
An MSP technician could believe they are simply connecting to a managed system. Instead, the connection itself may expose another endpoint to the attack chain.
This is particularly important for service providers because RMM infrastructure naturally connects large numbers of endpoints and organizations. The same capability that creates administrative efficiency can increase blast radius when abused.
RMM abuse is not theoretical. Huntress reported that 17.3% of threat-actor remote-access methods it observed in 2024 involved RMM abuse. Review the Huntress RMM abuse research.
There are several pieces to separate.
The incidents began through social engineering and rogue ScreenConnect deployments, but Huntress's investigation also uncovered a ScreenConnect file-transfer issue. ConnectWise subsequently assigned it CVE-2026-84869 and released remediation in ScreenConnect 26.6.5. Versions before 26.6.5 are affected.
ConnectWise says the issue affected ScreenConnect Remote Access Support and Access sessions across both cloud and on-premises deployments. The company's current guidance is to update to version 26.6.5 or later. Review the ConnectWise security advisories.
That patch should be treated as a priority.
But patching addresses only part of the larger lesson.
The attackers also relied on social engineering, legitimate remote-access software, VBScript, Windows Script Host, PowerShell, persistence mechanisms, and trusted Windows functionality.
Potentially, and in these incidents detection clearly mattered.
Huntress detected abnormal behavior when ScreenConnect spawned repeated wscript.exe processes, and Microsoft Defender reportedly quarantined one of the scripts in one incident. Huntress analysts intervened before portions of several attacks progressed further.
That is exactly why EDR and managed detection remain important.
But there is another useful question:
What if you did not have to detect the attack in order to stop it?
Detection requires identifying enough suspicious behavior to make a decision. Attackers increasingly try to make that decision harder by using legitimate software and native operating-system tools.
A trusted application may launch another trusted Windows component, which launches a script, which launches PowerShell, which retrieves or decrypts another payload.
Every individual component can appear legitimate in another context.
This is where prevention controls can complement detection.
The objective is not necessarily to recognize the ScreenConnect campaign, identify 1.vbs, discover a particular IP address, or classify the eventual payload.
Instead, the endpoint can restrict the actions those processes are permitted to perform.
For example, controls can constrain whether applications are allowed to launch child processes, manipulate sensitive files, access protected memory, establish persistence, introduce unauthorized executables, or modify protected portions of the Windows environment.
This attack illustrates an important principle:
Changing the attack does not necessarily change the endpoint actions the attacker ultimately needs in order to succeed.
The attacker can change the social-engineering lure, script names, payload, infrastructure, or encryption method. Eventually, however, something still needs to execute, modify the endpoint, establish persistence, access information, weaken defenses, or communicate externally.
Unknown does not automatically mean unstoppable.
AppGuard is a proven endpoint protection solution with more than a decade of production history focused on prevention through Isolation and Containment.
AppGuard restricts unauthorized endpoint behavior without requiring the attack to first be identified as malicious. It does not replace ScreenConnect security, patch management, EDR, or incident response. It provides another prevention layer designed to reduce what processes are allowed to accomplish after reaching the Windows endpoint.
AppGuard does not need to know the name of every attack to restrict the endpoint behaviors the attack may require. The attack may be new. The actions it needs to perform on a Windows endpoint often are not.
MSPs and organizations using ScreenConnect should first confirm that affected environments are running ScreenConnect 26.6.5 or later and review ConnectWise's current security guidance.
Huntress went further for systems confirmed to be affected, recommending reimaging from known-good media or performing a clean operating-system installation because of the complexity and persistence involved. Read the Hacker News coverage.
The ScreenConnect campaign is another example of why cybersecurity cannot depend entirely on distinguishing good software from bad software.
ScreenConnect is legitimate. PowerShell is legitimate. Windows Script Host is legitimate. Remote administration is legitimate.
The problem is what an attacker can make those tools do.
That shifts an important part of the security conversation from:
Is this application malicious?
to:
Should this application be allowed to perform this action?
Detect and Respond remains essential, particularly for identifying compromised accounts, infrastructure, and malicious activity across environments.
But MSPs managing hundreds or thousands of Windows endpoints should also consider how much execution freedom those endpoints really need.
The objective is not to predict every attack. It is to restrict the actions an attacker needs in order to succeed.
Primary research: Huntress investigation of rogue ScreenConnect installations
Remediation: ConnectWise ScreenConnect security advisories