# ScreenConnect Is Worm Food: How Attackers Turned a Remote Access Tool Into a Malware Distribution Network
Remote monitoring and management tools were supposed to make IT easier. They do — for defenders and attackers alike.
Huntress researchers have documented three separate incidents where threat actors turned ConnectWise ScreenConnect sessions into a self-spreading malware delivery mechanism, dropping a four-stage VBScript payload onto every new host that connected to a compromised ScreenConnect instance. The initial access methods varied — a Quick Assist tech-support scam in one case, a phishing-delivered MSI installer in another, and a third vector that appears to have involved a fake software installer — but the downstream behavior was the same: the moment a new machine checked in, it got hit.
That's the part that should keep defenders up at night.
## The Worm That Wasn't (But Functioned Like One)
Calling this "worm-like" is technically precise but undersells the threat. Traditional worms self-replicate by scanning networks. What Huntress observed is arguably more insidious: attackers seeded malicious payloads into an existing trusted channel, then waited. ScreenConnect's legitimate function — distributing files and executing commands across all connected clients — became the propagation engine.
The VBScript chain itself runs four stages. That level of staging isn't accidental. Multi-stage loaders exist to defeat signature-based detection: each layer is small, often legitimately-looking, and only the final stage contains the payload that most security tools are trained to catch. By the time stage four executes, the process tree looks like it originated from a trusted remote access agent.
VBScript as a vehicle is also telling. Microsoft has been deprecating VBScript in earnest since 2023, disabling it by default in newer Windows builds. But "newer" is doing a lot of work in that sentence — the enterprise install base is heavily weighted toward configurations that still have VBScript enabled, particularly in managed IT environments where software compatibility concerns slow OS updates. Attackers know this. VBScript payloads remain viable because the environments they target are exactly the ones least likely to have closed that door.
## Three Entry Points, One Exit Strategy
The diversity of initial access vectors across three unrelated incidents is significant. This isn't a targeted campaign with a signature approach — it's a technique being used by different actors (or the same actor with multiple toolkits) across different lure strategies. Tech-support scams, phishing, and fake installers are three distinct social engineering tracks aimed at three distinct victim profiles.
The common thread isn't the attacker. It's ScreenConnect.
That convergence suggests attackers have identified ScreenConnect deployments as high-value pivot points — not just for the access they provide to a single machine, but for the lateral spread potential they represent. Compromise one MSP's ScreenConnect instance and you've potentially accessed every client in their portfolio. The worm-like delivery mechanism means you don't even need to pivot manually; the tool does it for you at the next connection event.
ConnectWise ScreenConnect has been here before. The critical authentication bypass vulnerabilities disclosed in early 2024 — CVE-2024-1708 and CVE-2024-1709, with CVSS scores of 8.4 and 10.0 respectively — were exploited within days of disclosure, with ransomware groups and nation-state actors racing to abuse exposed instances. The attack surface hasn't changed fundamentally. The exploitation approach has just evolved from "break in directly" to "abuse what's already trusted."
## What Defenders Need to Understand Right Now
If your organization runs ScreenConnect, or if you're an MSP managing client environments through it, the defensive calculus here is specific:
---
## HackWire Analysis
The real story in this Huntress report isn't the VBScript chain — it's what the worm-like spread mechanism reveals about where RMM abuse is heading.
For years, the threat model for remote access tool compromise was linear: attacker gets in, attacker uses the tool to access and exfiltrate from that one environment. The technique documented here breaks that model. By treating a ScreenConnect deployment as a distribution network rather than a single access point, attackers have operationalized something closer to a software supply chain attack — except they don't need to compromise the vendor. They just need one MSP.
The implications for managed service providers are severe in a way that should prompt an industry conversation that isn't happening loudly enough. MSPs are attractive targets not despite their security tooling but *because* of it. A compromised RMM console gives attackers authenticated, trusted, often MFA-exempted access to dozens or hundreds of client networks simultaneously. The three incidents Huntress identified are almost certainly not the complete picture — they're the cases where detection worked.
There's also a timing dimension worth flagging. Microsoft's VBScript deprecation is real but slow. The gap between "deprecated by default in new builds" and "effectively unavailable across the enterprise" is measured in years, not months. Attackers are exploiting that gap deliberately, and the managed IT world — where legacy compatibility requirements keep old configurations alive longest — is the primary exposure zone.
The question defenders should be asking isn't "are we patched against the ScreenConnect vulns from 2024?" It's "would we know if our RMM was being used to push malware to our clients right now?" For most organizations, the honest answer is no.
— HackWire Editorial
---
## Related Coverage