Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts
-
Researchers have documented a curious wave of worm-like behavior tied to ConnectWise ScreenConnect, where rogue client instances are being used to push a malicious VBScript payload onto systems as they join a session. The activity, detailed by Huntress, hinges on a four-stage infection chain that ultimately delivers a payload to newly connected hosts—essentially turning the remote access tool into a distribution vector.
The three separate incidents observed so far share a common end goal but rely on widely different entry points, which suggests a level of adaptability in the operators' approach. Those initial vectors break down as follows:
- A tech-support scam abusing Microsoft Quick Assist to gain a foothold
- A phishing campaign delivering an MSI installer as the initial dropper
- A third, unidentified method that also led to the same ScreenConnect abuse
All three cases converge on the same post-exploitation routine: the attacker leverages the ScreenConnect client to drop a VBScript, which then progresses through additional stages before executing on the target. The scripting chain is notable for its modularity—each stage appears designed to fetch and execute the next piece, reducing the footprint left on disk at any single moment.
Huntress notes that the payload is specifically triggered when a new host connects to the rogue ScreenConnect server, implying the attackers have automated the delivery mechanism. This is not a case of a compromised legitimate server; rather, it points to threat actors hosting their own instance or modifying client behavior to achieve the desired spread.
For defenders, the key takeaway is to scrutinize any ScreenConnect client that initiates outbound connections to unapproved or unknown hosts. Organizations should also review their allowlists for remote access tools, particularly Quick Assist and ScreenConnect, since these are being repurposed rather than exploited through a vulnerability.
Mitigation steps to consider:
- Audit all ScreenConnect servers and clients in your environment for unauthorized instances.
- Restrict outbound connections from remote access tools to approved IP ranges or domains.
- Deploy behavioral detection rules for VBScript execution chains originating from remote support sessions.
- Monitor for Quick Assist or ScreenConnect process launches that do not correlate with active support tickets.
- Review MSI installer logs for unattended installation flags that could indicate phishing-driven deployment.
Source: The Hacker News
Are your remote support tools locked down to only sanctioned hosts, or could an unapproved ScreenConnect client connect out to an attacker-controlled server right now?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login