What broke

On 3 September, Huntress published research on modified ConnectWise ScreenConnect clients that behave like a worm. The rogue client watches for a new Host connection, registers script files with ScreenConnect’s virtual file-transfer system, and queues them to that Host with the action set to run. The Host executes them. Every new connection is a new infection.

The same day, ConnectWise issued a mitigation-only advisory about file transfer, with no CVE and no version upgrade required.

That has since changed, and if you read the earlier coverage you have stale information:

  • CVE-2026-84869 was published 8 September. CWE-862 missing authorisation plus CWE-269. CVSS 9.9.
  • Description: a condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorisation or Host confirmation.
  • It affects the client, not the server. Cloud and on-premise are both in scope.

One thing to be precise about: ConnectWise has not publicly confirmed a technical link between the file-transfer flaw and the Huntress campaign. The two arrived together and describe the same capability, but treating “the advisory is about this campaign” as vendor-confirmed fact would be overstating it.

Who is affected

Any ScreenConnect deployment where remote sessions are established with hosts you do not fully control — which is most MSP-shaped deployments.

On the fixed version: reporting points to 26.6.5, with all prior versions affected. I could not confirm that version number against ConnectWise’s own bulletin — the vendor page returned 403 on repeated attempts, and it rests on a single tracker. Verify the version against ConnectWise directly before you plan a rollout around it. I would rather flag that than print a number you act on and find wrong.

How victims are reached

Three routes, all social rather than technical:

  • Fake Quick Assist tech-support scams
  • Phishing delivering a malicious ScreenConnect.ClientSetup.msi
  • SEO-poisoned fake refund lures impersonating a well-known retailer’s tech support

None of these need a vulnerability. The CVE is what turns one compromised host into many.

What the payload does

Enough detail to recognise it, and no more.

A staged VBScript chain runs from the user’s temp directory. The first stage profiles the host before anything else happens — it checks for an existing ScreenConnect installation, enumerates security products by name (Huntress, CrowdStrike, SentinelOne, Sophos, Cisco AMP and Malwarebytes are all explicitly checked for), and measures available RAM against a 5GB threshold. The result is written to a file, and where the host looks unattractive the chain aborts.

That profiling step is itself a defensive signal: this campaign decides whether to proceed based on whether it thinks you have EDR.

Later stages retrieve a payload from cloud file hosting and decrypt it through several layers of obfuscation before execution. Three payload variants have been observed, selected by the profile result:

  • User-level backdoor — a second ScreenConnect instance under the attacker’s control.
  • Persistence and privilege escalation — a UAC bypass through a hijacked protocol handler, an AMSI bypass, and — the one that matters most operationally — adding all of C:\Users as a Microsoft Defender exclusion path.
  • Tunnelling and mining — a tunnelling utility masquerading as Themes.exe, XMRig renamed to SearchIndex.exe, and a known-vulnerable WinRing0 driver installed as svcdrv64.sys. This variant also disables Defender reporting and notifications, and turns off HVCI memory integrity.

That last variant leaves the machine measurably less defended than it found it, and those changes survive removal of the malware.

How to detect it

The durable detection is in the ScreenConnect audit log, not in the filenames. Huntress explicitly warns that the script names will change. What does not change is the shape of the activity:

ScreenConnect audit log entries showing RunFiles or RanFiles where Process: Guest.

That is the behaviour the CVE describes, and it holds regardless of what the payload is called this week.

Supporting signals, in rough order of usefulness:

  • ScreenConnect.WindowsClient.exe spawning wscript.exe. This is what Huntress alerted on. Generalise it: any Windows Script Host or PowerShell execution parented to a ScreenConnect session process.
  • Run key HKCU\Software\Microsoft\Windows\CurrentVersion\Run with the value name WindowsServiceHost, pointing at a .vbs in the user’s AppData.
  • A Defender exclusion covering C:\Users. Almost nothing legitimate does this. If you can query exclusion paths across your estate, that single check is worth running today whether or not you use ScreenConnect.
  • Unexpected Themes.exe, SearchIndex.exe, or svcdrv64.sys — legitimate-looking names in illegitimate places.
  • HVCI or Defender reporting silently disabled.

Network indicators, from the Huntress IOC table: 45.13.237[.]190 (associated with tele-sync.opik[.]net), 131.123.40[.]98 on port 8041, 146.59.55[.]107, 45.32.192[.]150, 15.204.185[.]204. Domains borertors92.anondns[.]net and homehub.opik[.]net. A backdoored ScreenConnect instance ID of 7a4d7d66502d4260 has also been reported.

Of those, 146.59.55[.]107 appears only in the Huntress table and not in any secondary coverage — no reason to doubt it, but you should know which indicators have one source and which have several.

On file hashes: Huntress published them and I am deliberately not reproducing them here, because I could not verify them to my own satisfaction against the primary source. Pull them from the Huntress IOC table directly. A wrong hash in a detection rule is worse than no hash — it produces confident silence.

What to do

1. Patch the client, once you have confirmed the fixed version with ConnectWise.

2. Remove the file-transfer permission, which works immediately and needs no upgrade:

Administration → Security → Roles → edit each role → for each session group, open Scoped Permissions and deselect TransferFiles (or TransferFilesInSession on older versions). This has to be repeated across every role — one missed role is an open path.

Even after patching, this is sound defence in depth for MSP-style deployments. Very few workflows genuinely need every role to push files into every session.

3. Reimage compromised hosts. Huntress’s judgement is that the chains are too extensive for in-place cleanup, and given the Defender exclusions, disabled HVCI, and installed vulnerable driver, that is hard to argue with. Rebuild from known-good media.

4. Audit for ScreenConnect you did not install — including on-premise instances — and for secondary remote-access tools such as UltraViewer or Quick Assist showing up on affected machines.

The part worth remembering

The interesting property of this campaign is not the malware, which is unremarkable. It is that the remote access tool itself is the propagation mechanism, using a documented product feature working roughly as designed, and that the initial access is a phone call rather than an exploit.

Detections keyed to script names will decay within weeks. A detection keyed to a guest process running files inside a support session describes the actual capability, and will still be true after the payload is rewritten.

References

  • Huntress — Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity, 3 September 2026
  • ConnectWise — ScreenConnect security bulletin, 8 September 2026
  • NVD — CVE-2026-84869