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 improper privilege management. CVSS 9.9. NVD status is still “Received” — the record is CNA-supplied and not yet NVD-enriched.
  • 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.

The fixed version is 26.6.5. ConnectWise’s 8 September bulletin states it directly: upgrade to 26.6.5 or later, with all prior versions affected. NVD agrees.

One conflict to be aware of: Huntress’s 8 September update tells readers to upgrade to 26.6.6, while also noting ConnectWise considers versions prior to 26.6.5 impacted. 26.6.5 is the fix line; 26.6.6 was simply the current release when Huntress wrote. Either satisfies the requirement — but if you are writing a change ticket, 26.6.5 is the number the vendor is standing behind.

Cloud servers were remediated by ConnectWise, so there is no server-side action for cloud customers. Cloud customers still have to reinstall host clients and access agents.

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, and measures available RAM against a 5GB threshold (a virtual-machine check). Huntress names Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos and Malwarebytes “as well as others”, and other coverage adds Symantec Endpoint Protection — so treat that list as examples, not the full set. 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, paired with tele-sync.opik[.]net
  • 131.123.40[.]98 on port 8041
  • homehub.opik[.]net on 443 — the tunnelling destination
  • borertors92.anondns[.]net
  • Backdoored ScreenConnect instance ID 7a4d7d66502d4260

Two more appear in the same table but mean something different: 146.59.55[.]107 and 45.32.192[.]150 are attributed by Huntress to UltraViewer connections in a separate 20 August incident, not to ScreenConnect command-and-control. Worth hunting for, but do not file them as this campaign’s C2.

Those two, and 15.204.185[.]204, appear only in the Huntress table and in no secondary coverage. No reason to doubt them — but you should know which of your indicators rest on one source.

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.

From the 8 September bulletin: Administration → Security → Roles → edit each role → review each session group with permissions assigned → deselect TransferFiles → save. Repeat for every role; one missed role is an open path.

On legacy versions the permission is named TransferFilesInSession — that name comes from the earlier 3 September advisory, not the bulletin.

ConnectWise is explicit that this is a temporary mitigation and not a substitute for installing the update.

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