Criminals Turned a Remote-Support Tool Into a Worm. Here Is the One Question to Ask Your IT Provider.

If you have ever watched a support technician move your mouse from a hundred miles away, there is a good chance the tool doing it was ScreenConnect. It is widely used by IT providers, and it is a fine product for what it does. Which is exactly why criminals wanted their own copy.

Since late August, attackers have been tricking people into installing a rogue ScreenConnect client, one that connects back to a server the attackers run instead of your provider. ConnectWise has since patched a critical flaw in the client, CVE-2026-84869, rated 9.9 out of 10, that allows files to be transferred and run through an active session without authorization, which is the behavior researchers observed: the files disable defenses, install a hidden backdoor, and copy themselves to the next machine that connects. Security researchers at Huntress, who documented the campaign, describe the behavior as worm-like. ConnectWise published a fix on September 8. CISA added the flaw to its list of actively exploited vulnerabilities on September 11 and gave federal agencies three days to patch.

This post covers what the attack does, why the honest fix for an infected machine is to wipe it, and the one question worth asking whoever provides your IT support this week.

What Huntress saw

Huntress documented three incidents at three unrelated organizations, on August 20, August 20, and August 24. None of them began with a hack. They began with a person doing something that looked reasonable.

In one case an employee was talked into running Windows Quick Assist, which then led to a ScreenConnect client being deployed. In another, a phishing email led the victim to download and run a ScreenConnect installer. In the third, someone searching for a "Geek Squad refund form" was steered to a download that was really a ScreenConnect client. Each client connected to infrastructure the attackers controlled.

From there a chain of four small scripts ran. The first profiled the machine: how much memory it had (a common check for virtual machines), whether ScreenConnect was already installed, and which security products were present. Huntress notes the script checks by name for Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos, and Malwarebytes, and records the answer in the value that decides which payload runs. The second pulled an obfuscated file from a Dropbox link containing the next set of addresses and encryption keys. The third picked one of three encrypted payloads based on what the first script found. The fourth decrypted it, ran it through PowerShell, and copied all four scripts to a public folder on the machine so they could be passed along.

That last step is the worm part. Huntress found that the modified ScreenConnect client watches for new sessions and, when one appears, uses ScreenConnect's own file-transfer feature to send the four scripts to the newly connected machine and queue them to run. The flaw is what lets that happen without the person at the other end approving anything.

What the payloads do

Depending on the machine, the payload did one of three things. The "access" version bypassed User Account Control, tried to disable Windows' script scanning, added the entire C:\Users folder to Microsoft Defender's exclusion list, turned off sleep and hibernation so the machine stays reachable, and installed a hidden second ScreenConnect backdoor. The "combo" version went further: it disabled Defender's reporting and a core Windows security feature, installed a tunneling proxy disguised as Themes.exe, dropped a cryptocurrency miner disguised as SearchIndex.exe, and loaded a known-vulnerable driver of the kind attackers use to get kernel-level access. In one of the incidents a second remote-control tool, UltraViewer, was installed as well.

Persistence came from a registry entry named WindowsServiceHost, pointing to a script in the user's AppData folder. It survives a reboot. It does not survive a reimage, which is why Huntress's team recommended that affected hosts be reimaged from known-good media or given a clean operating system install. That is the honest answer for a machine where an attacker has had kernel access and installed their own remote-control tool, and it is worth hearing from a security firm rather than from us.

Why this matters to a 10 to 500 person business

Two reasons, and they point in different directions.

First, the entry point is a person, not a port. Nobody scanned your firewall. Someone got a convincing phone call, a convincing email, or a convincing search result, and installed what they were told to install. That is the same pattern as the paste-this-command attacks we covered earlier this week, with a remote-support tool in place of a terminal command. The rule is the same: legitimate support does not arrive unannounced and ask you to install something. If your IT provider needs to connect, you should already know who they are and how they reach you.

Second, the tool itself is one your provider probably uses, and the fix is not only on the server. According to ConnectWise's guidance as reported by Arctic Wolf, cloud-hosted ScreenConnect was updated automatically, but the client software on each managed computer has to be refreshed separately. Shadowserver counted more than 1,000 unpatched, internet-exposed ScreenConnect instances after the fix shipped, 758 of them in North America. So the question to ask your provider is specific: is your ScreenConnect on version 26.6.5 or later, and have the clients on our machines been refreshed? A good provider will answer in one sentence. A vague answer is information too.

Where the endpoint layer fits

Everything in this chain after the first click is behavior on the endpoint: script hosts launched from a remote-support session, a scheduled series of scripts pulling encrypted payloads, a registry key for persistence, changes to Defender's exclusions, a vulnerable driver loading, a miner and a tunnel appearing as system-sounding names. Most of it is not a known-bad file that antivirus can match against a list. Notably, the attackers' own first script checks which endpoint products are installed and feeds the answer into the choice of payload. They plan around that layer.

Our managed endpoint protection runs on SentinelOne, whose platform SentinelOne says uses static and behavioral AI engines on the device and what it calls autonomous, machine-speed prevention, killing and quarantining unauthorized processes in real time. Whether a given chain is stopped at step one or step three depends on the configuration, which is why we manage the configuration and a named engineer reviews what the platform flags. Our managed email security, built on Check Point Harmony Email and Collaboration, is the layer in front of the phishing lure. And patching your own tools, including the ones you use to help customers, is part of the job for any provider; it is why we keep a what-to-patch-first habit rather than a once-a-quarter one.

We work with small and medium businesses nationwide from our home base in McLean, Virginia. If you are not sure what remote-support tools are installed on your machines, or who can connect to them, book a free 15-minute call. We will show you how to see every remote-access tool on your endpoints and what a rogue one looks like.

Sources: Huntress, "Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity" (Sept 9, 2026); ConnectWise security bulletin for CVE-2026-84869 (Sept 8, 2026) as reported by SecurityWeek, BleepingComputer, and Arctic Wolf; CISA Known Exploited Vulnerabilities catalog (Sept 11, 2026); Shadowserver exposure counts as reported by BleepingComputer; SentinelOne and Check Point product materials for vendor claims.