- The Mess: Huntress has uncovered rogue ScreenConnect installations that can automatically spread malware to newly connected Windows machines. The attackers modified the legitimate remote-support client so every new support session could become another infection opportunity.
The campaign showed up across several unrelated organizations in late August.
At first, the incidents looked like ordinary abuse of remote-access software.
They weren’t.
Huntress found modified ScreenConnect clients repeatedly launching Windows Script Host and executing four VBScript files: 1.vbs, 2.vbs, 3.vbs and 4.vbs.
The scripts profile the machine, check for security software, establish persistence and download additional payloads.
Those payloads can include backdoored ScreenConnect components, privilege-escalation tools, tunneling software and cryptocurrency miners.
Then Huntress found the part that changes the story.
The compromised ScreenConnect client watches incoming remote-support sessions.
When another computer connects, the malicious client automatically transfers the same scripts to that machine and triggers the infection chain.
No second phishing email is required.
No second fake installer is required.
The support session itself becomes the delivery mechanism.
- The Damage: One compromised workstation can become a distribution point for malware reaching technicians, help-desk systems and other Windows endpoints connected through ScreenConnect sessions.
This is particularly nasty for IT departments.
Imagine a technician connecting to an infected workstation because the user reports a problem.
The technician thinks they’re helping.
The compromised ScreenConnect client thinks otherwise.
It pushes the malicious scripts toward the newly connected endpoint.
That creates a very different attack path from traditional RMM abuse.
Normally, attackers compromise one endpoint and use remote-access software to maintain control.
Here, the compromised remote-access client can help propagate the intrusion.
Huntress observed the same basic pattern across multiple organizations, despite no obvious connection between those environments. Some infected machines also contained other remote-access software such as UltraViewer, suggesting that attackers were establishing redundant access channels.
The initial infection still requires social engineering.
Huntress observed cases involving fake technical-support interactions, malicious ScreenConnect installers and deceptive software-download scenarios.
But once the rogue client is installed, the propagation mechanism changes the economics of the attack.
The attacker doesn’t need to convince every subsequent victim to click something.
The compromised environment does part of the work.
Huntress also observed attempts to interfere with Microsoft Defender reporting and bypass User Account Control.
That moves this well beyond a nuisance remote-access Trojan.
- The Fix: Huntress recommends treating confirmed infections as full compromises, reimaging affected machines from known-clean media and auditing ScreenConnect activity for suspicious
RunFilesorRanFilesevents associated with aGuestprocess.
Administrators should specifically hunt for unexpected execution of:
1.vbs
2.vbs
3.vbs
4.vbs
and suspicious wscript.exe processes spawned from ScreenConnect-related locations.
The WindowsServiceHost user Run Key pointing to WindowsServiceHost.vbs in a user’s AppData directory is another indicator Huntress observed.
But defenders shouldn’t rely exclusively on filenames.
Attackers can rename scripts.
The more durable detection signal is abnormal Windows Script Host or PowerShell execution associated with ScreenConnect sessions and unexpected file-transfer activity.
IT teams should also inspect ScreenConnect audit logs.
Huntress says RunFiles or RanFiles entries showing suspicious scripts executed from a Process: Guest context should be treated as an immediate red flag.
If a technician recently connected to a confirmed infected endpoint, that technician’s workstation deserves investigation too.
And if compromise is confirmed, Huntress recommends reimaging rather than attempting to surgically remove the malware.
That’s the right call.
Once an attacker has established persistence and deployed additional remote-access tooling, “delete the bad file” is not an incident-response strategy.
Bugstoday Opinion
This is what happens when attackers stop abusing a legitimate tool and start modifying the tool itself.
ScreenConnect isn’t the vulnerability here.
The problem is the rogue client.
But that distinction doesn’t make the attack less dangerous.
IT teams trust remote-support software because that’s literally its job.
A technician connects to a workstation.
The connection is legitimate.
The software is legitimate.
The user requested support.
And yet the infected endpoint can turn that completely normal workflow into a malware delivery mechanism.
That’s the clever part.
The worm doesn’t need to crawl across SMB. It rides the help desk.
RMM software already has privileged access, network reach and human trust.
Give a compromised client the ability to push itself into new sessions and you’ve built a propagation engine without needing a traditional worm exploit.
For defenders, the lesson is uncomfortable:
Your remote-support session can be an infection boundary.
Treat it like one.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
Huntress — Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity
IT Security Guru — Hijacked ScreenConnect Installs Spreading Malware Like a Worm
CybersecurityNews — Hackers Weaponize ScreenConnect to Spread Worm-Like Malware
AlienVault OTX — ScreenConnect Worm-Like Campaign Indicators
