A remote access tool built for IT departments and help desks is now being weaponized against them. Researchers at Huntress say they've found hacked versions of ConnectWise's ScreenConnect software that don't just give attackers a foothold on one machine, they use that foothold to infect whoever connects to it next, turning a single compromised endpoint into a launching pad for further attacks.
Huntress said its Security Operations Center issued three critical incident alerts in late August after spotting the same unusual pattern across customer networks that had nothing else in common. In each case, a rogue ScreenConnect client had been planted through social engineering, and once running, it began quietly automating an infection chain that most victims never saw coming.
Three break-ins, one playbook
The entry points varied, but the outcome didn't. On August 20, Huntress caught a case that started with a classic tech support scam: someone called a victim claiming their computer had been hacked, then walked them through opening Quick Assist, the remote help tool that ships with Windows, and handing over control. Once inside, the attacker installed a ScreenConnect client wired to call home to a server at 45.13.237[.]190, an address that VirusTotal had tied to a domain called tele-sync.opik[.]net earlier that same month.
A second incident, logged the same day, took a different path in. The victim ran a file called ScreenConnect.ClientSetup.msi straight out of a Microsoft Edge downloads folder, almost certainly after clicking through a phishing email. That installer set up a client pointed at a separate server, 131.123.40[.]98, over port 8041. Huntress later found the same machine reaching out to several more IP addresses tied to the campaign's infrastructure.
The third case, on August 24, started with something almost mundane: a person searching online for a Geek Squad refund form. Instead of a form, they got a rogue ScreenConnect.Client.exe that connected back to a domain named borertors92.anondns[.]net. Huntress shut this one down quickly enough that it never progressed past the initial script execution.
Different bait, same result. Once the ScreenConnect client landed on a machine, it began repeatedly calling wscript.exe, the built-in Windows scripting engine, to fire off four files named, plainly, 1.vbs, 2.vbs, 3.vbs and 4.vbs.
What the four scripts actually do
Huntress pulled the scripts apart and found a loader designed to feel its way around a system before deciding what to drop on it.
The first script checks whether ScreenConnect is already installed, looks for security software including Huntress's own agent, CrowdStrike, SentinelOne, Sophos, Malwarebytes and Cisco AMP, and checks how much memory the machine has, likely a crude way of ruling out sandboxes and virtual machines used by researchers. It boils all of that down into a three-digit code and drops it into a file called value.txt in the Windows temp folder.
The second script waits for that file to appear, then fetches a link from Dropbox, decodes it and stores the result as a lookup table. Each possible three-digit combination in that table maps to a different payload and a different AES decryption key. The third script reads the table, matches it against the code generated earlier, and downloads whichever payload fits. The fourth script grabs the matching decryption key, builds a PowerShell script from scratch inside the VBScript itself, and runs it with Windows' script execution safeguards switched off.
That PowerShell script does the actual unwrapping, decrypting the downloaded file and handing control to a second, more capable PowerShell script that Huntress found renamed as PyTorchFix.ps1. Depending on which of the three outcomes the profiling scripts settled on, the victim ends up with either a bare-bones backdoored ScreenConnect client, a version bundled with tools for privilege escalation and persistence, or the full package: tunneling software and a cryptocurrency miner thrown in as well.
One small detail stood out to the researchers. A comment buried in the third script spells out the payload table's format in plain, tutorial-style language, the kind of explanatory note that reads less like something a human attacker jotted down and more like something an AI coding tool generated on the fly.
How the infection spreads on its own
This is the part that makes the campaign unusual. Buried in the backdoored ScreenConnect client is code that watches ScreenConnect's own connection list for new sessions. The moment somebody new connects, whether that's another victim, a technician, or anyone else routed through the same infrastructure, the client repackages all four VBScript files, hands them to ScreenConnect's built-in file transfer feature, flags them to run automatically, and pushes them straight to the new arrival.
Huntress described it as the modified client using the server's own connection status data to figure out who just showed up, then quietly loading them up with the same infection. The client keeps a short memory of which sessions it has already hit so it doesn't repeat itself mid-session, but that memory resets once someone disconnects, meaning a second visit from the same person can trigger the whole thing over again.
The heavier version of the payload came with extras: a copy of the tunneling tool wstunnel disguised under the filename Themes.exe, reaching out to homehub.opik[.]net over port 443; an XMRig cryptocurrency miner renamed SearchIndex.exe; and a known vulnerable driver called WinRing0, saved as svcdrv64.sys, which attackers commonly use to get code running with elevated privileges. The malware also went after Windows Defender directly, disabling its reporting and notifications and switching off a hardware-level protection called Hypervisor-Protected Code Integrity. In at least one case, the attackers also dropped a second remote access tool, UltraViewer, apparently as a fallback in case ScreenConnect got pulled.
Huntress caught and stopped all three original incidents before the attackers finished the job, but the firm says it has continued to see the same pattern show up elsewhere since. Because the malware digs in so deep, wiping the affected machines and rebuilding them from clean media is what Huntress is telling customers to do rather than trying to clean an infected system in place.
Where ConnectWise fits in, and where it doesn't
Huntress says it's been talking with ConnectWise throughout the investigation, and on September 3, ConnectWise published its own advisory describing a problem with file transfer behavior in ScreenConnect's Remote Access, Support and Access sessions, affecting both the cloud-hosted version and self-hosted, on-premises deployments.
The company said a CVE number and an official patch are coming within the week. In the meantime, it's telling ScreenConnect administrators to go into Administration, then Security, then Roles, and check whether the TransferFiles permission, called TransferFilesInSession in older builds, is switched on for any assigned role. If it is, ConnectWise says to turn it off, a change that doesn't require updating ScreenConnect itself and can be applied right away.
One thing worth being precise about: ConnectWise has not said the file transfer issue is technically the same vulnerability the Huntress campaign is exploiting. The advisory and the Huntress research came out around the same time and clearly describe related territory, file transfer abuse inside ScreenConnect sessions, but the company has stopped short of confirming a direct link between the two.
Huntress, for its part, is telling anyone running ScreenConnect on-premises to take a closer look at their deployments regardless. The firm recommends digging through ScreenConnect's server-side audit logs for RunFiles or RanFiles entries tied to a Guest process, especially any referencing unfamiliar VBScript or PowerShell activity, and treating that as an immediate red flag. Huntress also cautioned that the exact filenames tied to this campaign will likely change as the attackers adjust, so the underlying behavior, scripted execution launched through a ScreenConnect session, matters more than the specific file names.
Not the first time ScreenConnect has been a target
This isn't ScreenConnect's first brush with mass exploitation. In February 2024, ConnectWise disclosed a pair of vulnerabilities in the product, an authentication bypass rated a perfect 10 on the CVSS scale and a path traversal flaw alongside it, that let attackers create administrator accounts on exposed servers without needing valid credentials. Proof-of-concept code for those bugs went public within days, and Huntress's own CEO at the time called it the makings of what could be the biggest cybersecurity incident of that year, given that a single exploited server could hand attackers control over thousands of downstream endpoints managed through it.
What followed was a scramble. Security vendors including Sophos and Darktrace tracked ransomware built from a leaked LockBit builder tool being dropped through the exploited servers, alongside Cobalt Strike beacons and remote access trojans. The Cybersecurity and Infrastructure Security Agency later added one of the two flaws to its Known Exploited Vulnerabilities catalog. More recently, other research teams have logged waves of signed ScreenConnect droppers used in financial sector phishing campaigns, and industry researchers have generally flagged remote monitoring and management software as one of the more consistently abused categories of legitimate IT tooling over the past couple of years, precisely because it's designed to do the thing attackers want: get full control of a machine without tripping the alarms a piece of unfamiliar malware would.
The current campaign fits that same pattern in terms of how attackers get in, but the automated, self-spreading distribution mechanism built into the client itself is new territory, and it's the detail that has researchers paying closer attention this time around.
