Threat actors are turning one of the most common legitimate remote access tools in the enterprise — ConnectWise ScreenConnect — into a self-propagating malware delivery mechanism. According to research published by Huntress, three unrelated incidents have been observed in which rogue ScreenConnect clients distributed a malicious, four-stage Visual Basic Script (VBScript) chain to newly connected systems, exhibiting worm-like behavior across victim environments.
This is not a vulnerability in ScreenConnect itself. This is abuse of a trusted remote monitoring and management (RMM) channel — a technique class that continues to evade perimeter controls because the traffic, the binary, and the connections all look legitimate. If your organization runs ScreenConnect, or if your endpoints can be reached by a technician's ScreenConnect instance, you are in the blast radius. SOC teams need detections for this behavior today.
What Happened
Huntress documented three separate intrusions that converged on the same payload delivery mechanism. The initial access vectors were diverse, which tells us this is a technique being adopted across multiple threat actors rather than a single campaign:
- Quick Assist tech-support scam: Operators social-engineered victims into granting access via Microsoft's built-in Quick Assist tool (
quickassist.exe), a technique popularized by ransomware affiliates over the past two years and still running strong in 2026. - Social engineering-delivered MSI installer: Victims were lured into executing a malicious MSI package, giving attackers their initial foothold.
- Fake (fraudulent) lure: A third social engineering vector delivering the same downstream chain.
Once initial access was established, the attackers deployed or leveraged ScreenConnect. The critical behavioral pivot: when the ScreenConnect client established new connections to additional hosts, a malicious VBScript payload was pushed to those newly connected systems. The payload itself is a four-stage VBScript chain — staged script execution designed to fragment the malicious logic, complicate static detection, and frustrate analysis. Because the delivery mechanism rides the RMM's own client connection workflow, the malware inherits the trust and reach of the ScreenConnect deployment, spreading laterally in a worm-like fashion without requiring any exploit.
Technical Analysis
Affected Products and Platforms
- ConnectWise ScreenConnect — both cloud-hosted and on-premises instances where clients are deployed to endpoints. The abuse targets the client-to-host connection workflow, not a software flaw.
- Windows endpoints — the payload is VBScript, executed via the Windows Script Host (
wscript.exe/cscript.exe). - Microsoft Quick Assist — abused as an initial access vector; any Windows 10/11 host with Quick Assist available is exposable to the social engineering lure.
No CVE is associated with this activity. This is legitimate-tool abuse (living-off-the-land / living-off-the-RMM), which is precisely why traditional vulnerability management will not catch it. Your patch cadence is irrelevant here; your behavioral detection and RMM governance are what matter.
Attack Chain (Defender's View)
- Initial access — Quick Assist scam, trojanized MSI, or a fake lure. Observable artifacts:
quickassist.exeexecution initiated by end users (not IT),msiexec.exeinstalling packages from user-writable or temporary paths, and browser-downloaded installers executed fromDownloads. - RMM staging — A rogue or attacker-controlled ScreenConnect client is present in the environment, or an existing deployment is abused. Watch for unexpected ScreenConnect instances, new service installations, and ScreenConnect clients checking in from infrastructure you don't recognize.
- Propagation trigger — When the ScreenConnect client connects to a new host, the four-stage VBScript is delivered and executed on the target. Observable artifact: the ScreenConnect client process spawning
wscript.exeorcscript.exe, or script files appearing in temp/user profile directories immediately following a new RMM session. - Staged script execution — Multi-stage VBScript chains typically decode, deobfuscate, and invoke follow-on payloads. Expect child processes of the script host (PowerShell,
mshta.exe,rundll32.exe,certutil.exe) and outbound C2 from the newly compromised host.
Exploitation Status
This is confirmed in-the-wild activity across three unrelated incidents, per Huntress. This is not theoretical. Because the technique requires no exploit and uses signed, legitimate software, assume it is already being replicated by other actors. Any organization with unmanaged or unmonitored RMM tooling should treat this as an active threat, not an emerging one.
Detection & Response
This is a technical threat. The detections below target the two highest-fidelity behaviors: (1) the ScreenConnect client spawning a script interpreter, and (2) script hosts executing from user-writable staging locations consistent with the four-stage VBScript delivery.
Sigma Rules
---
title: ScreenConnect Client Spawning Windows Script Host
id: 3f8c1a52-7d94-4b21-9e63-2a5c7f01d8b4
status: experimental
description: Detects the ConnectWise ScreenConnect client process spawning wscript.exe or cscript.exe, consistent with the worm-like VBScript delivery to newly connected hosts reported by Huntress.
references:
- https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
- https://attack.mitre.org/techniques/T1059/005/
- https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.execution
- attack.t1059.005
- attack.command_and_control
- attack.t1219
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\ScreenConnect.ClientService.exe'
- '\ScreenConnect.WindowsClient.exe'
selection_child:
Image|endswith:
- '\wscript.exe'
- '\cscript.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare legitimate ScreenConnect automation scripts deployed by administrators; validate against approved RMM script inventories
level: high
---
title: VBScript Execution from User-Writable Staging Directories
id: 9d2e4b17-6a35-4c88-b1f4-8e3d6a02c5f9
status: experimental
description: Detects Windows Script Host executing .vbs or .vbe files from temporary or user profile directories, consistent with staged VBScript payload delivery observed in the ScreenConnect propagation incidents.
references:
- https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
- https://attack.mitre.org/techniques/T1059/005/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.execution
- attack.t1059.005
logsource:
category: process_creation
product: windows
detection:
selection_image:
Image|endswith:
- '\wscript.exe'
- '\cscript.exe'
selection_path:
CommandLine|contains:
- '\AppData\Local\Temp\'
- '\AppData\Roaming\'
- '\Users\Public\'
- '\ProgramData\'
selection_ext:
CommandLine|contains:
- '.vbs'
- '.vbe'
- '.js'
- '.jse'
condition: selection_image and selection_path and selection_ext
falsepositives:
- Legacy logon scripts or software deployment tooling; baseline and allowlist known-good script paths
level: medium
---
title: Quick Assist Execution Followed by Script Host or Installer Activity
id: 5b7f3c91-2e48-4d16-a9c2-6f1b8d04e7a3
status: experimental
description: Detects Quick Assist spawning script interpreters or msiexec, consistent with tech-support scam initial access that preceded ScreenConnect VBScript propagation in the reported incidents.
references:
- https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
- https://attack.mitre.org/techniques/T1219/
- https://attack.mitre.org/techniques/T1659/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.execution
- attack.t1219
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\quickassist.exe'
selection_child:
Image|endswith:
- '\wscript.exe'
- '\cscript.exe'
- '\powershell.exe'
- '\msiexec.exe'
- '\mshta.exe'
condition: selection_parent and selection_child
falsepositives:
- Legitimate helpdesk sessions running remediation scripts; correlate with IT ticket records
level: high
KQL (Microsoft Sentinel / Defender)
The following hunt correlates ScreenConnect client activity with script host execution across your endpoint telemetry. Run it over a 14-day lookback first, then convert to an analytics rule scoped to a 1-hour window.
// Hunt: ScreenConnect client spawning script hosts or script files dropped post-connection
let ScriptHosts = dynamic(["wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe"]);
let ScreenConnectProcs = dynamic(["ScreenConnect.ClientService.exe", "ScreenConnect.WindowsClient.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any (ScreenConnectProcs)
and (FileName has_any (ScriptHosts)
or ProcessCommandLine has_any (".vbs", ".vbe", ".jse"))
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, AccountName, SHA256, ReportId
| order by TimeGenerated desc;
// Secondary: Quick Assist or msiexec delivering script payloads
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "quickassist.exe"
or (FileName =~ "msiexec.exe" and ProcessCommandLine has_any ("http", "Temp", "Downloads"))
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;
Velociraptor VQL
Use this hunt artifact to sweep endpoints for ScreenConnect processes with suspicious child script hosts and for recently staged VBScript files in user-writable locations.
-- Hunt for ScreenConnect-spawned script hosts and staged VBScript artifacts
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)wscript|cscript|mshta'
AND CommandLine =~ '(?i)\.vbs|\.vbe|\.jse'
AND CommandLine =~ '(?i)appdata|programdata|users\\\\public|temp')
OR Name =~ '(?i)quickassist'
-- Companion sweep: recently modified script files in staging directories
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['C:/Users/*/AppData/Local/Temp/*.vbs',
'C:/Users/*/AppData/Local/Temp/*.vbe',
'C:/Users/*/AppData/Roaming/*.vbs',
'C:/ProgramData/*.vbs',
'C:/Users/Public/*.vbs'])
WHERE Mtime > now() - 86400 * 7
ORDER BY Mtime DESC
Remediation and Hardening Script
The following PowerShell audits a Windows endpoint for rogue ScreenConnect instances, suspicious staged scripts, and unauthorized Quick Assist presence, and disables Windows Script Host where not operationally required. Test in a pilot group before broad deployment — WSH disablement will break legacy logon scripts.
# ScreenConnect VBScript Worm - Audit and Hardening Script
# Run elevated. Review output before applying -DisableWSH in production.
param([switch]$DisableWSH)
$Report = @()
# 1. Identify ScreenConnect services and their binary paths
Get-CimInstance Win32_Service | Where-Object { $_.Name -match 'ScreenConnect' -or $_.DisplayName -match 'ScreenConnect' } | ForEach-Object {
$Report += [PSCustomObject]@{ Check='ScreenConnectService'; Detail="$($_.Name) | $($_.PathName) | State=$($_.State)" }
}
# 2. Flag staged script files in user-writable locations (last 7 days)
$Cutoff = (Get-Date).AddDays(-7)
$Paths = @("$env:TEMP", "$env:ProgramData", "C:\Users\Public")
foreach ($UserDir in (Get-ChildItem 'C:\Users' -Directory -ErrorAction SilentlyContinue)) {
$Paths += "$($UserDir.FullName)\AppData\Local\Temp"
$Paths += "$($UserDir.FullName)\AppData\Roaming"
}
foreach ($P in $Paths) {
Get-ChildItem $P -Include *.vbs,*.vbe,*.jse -Recurse -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt $Cutoff } | ForEach-Object {
$Report += [PSCustomObject]@{ Check='StagedScript'; Detail="$($_.FullName) | Modified=$($_.LastWriteTime)" }
}
}
# 3. Check Quick Assist presence (remove if not required by helpdesk policy)
$QA = Get-AppxPackage -Name '*QuickAssist*' -ErrorAction SilentlyContinue
if ($QA) { $Report += [PSCustomObject]@{ Check='QuickAssist'; Detail="Present: $($QA.Name) $($QA.Version) - remove if not approved" } }
# 4. Enumerate unauthorized RMM tooling commonly abused alongside ScreenConnect
Get-CimInstance Win32_Service | Where-Object { $_.Name -match 'AnyDesk|TeamViewer|Atera|Splashtop|LogMeIn|DWService' } | ForEach-Object {
$Report += [PSCustomObject]@{ Check='RMMTool'; Detail="$($_.Name) | $($_.PathName)" }
}
# 5. Optionally disable Windows Script Host (breaks legacy scripts - pilot first)
if ($DisableWSH) {
New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows Script Host\Settings' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows Script Host\Settings' -Name 'Enabled' -Value 0 -Type DWord
$Report += [PSCustomObject]@{ Check='WSH'; Detail='Windows Script Host disabled (Enabled=0)' }
}
$Report | Format-Table -AutoSize
$Report | Export-Csv -Path "$env:ProgramData\ScreenConnect_Audit_$(Get-Date -Format yyyyMMdd_HHmm).csv" -NoTypeInformation
Remediation
Because this activity abuses legitimate software rather than exploiting a CVE, remediation is architectural and procedural — not a patch cycle. Prioritize the following:
- Inventory and govern every RMM instance. Enumerate all ScreenConnect deployments (and every other RMM tool) in your environment. Anything not owned, licensed, and monitored by your IT organization is rogue — remove it immediately. Maintain an allowlist of approved RMM binaries and alert on any deviation.
- Restrict ScreenConnect session behavior. Where your ScreenConnect licensing permits, restrict which technicians and source IPs can initiate sessions, enforce MFA on the technician portal, and audit session logs for connections initiated outside change windows or to hosts outside normal scope.
- Disable or constrain Windows Script Host. The four-stage chain depends on
wscript.exe/cscript.exe. If your environment has no hard dependency on VBScript (validate logon scripts, legacy apps, and deployment tooling first), disable WSH via the registry key in the script above, or use Attack Surface Reduction rules to block script hosts from launching child processes and Office/script abuse. - Neutralize Quick Assist as an initial access vector. If your helpdesk does not use Quick Assist, remove it (
Get-AppxPackage) or block it via AppLocker/WDAC. If it is used, train users that IT will never cold-call and request a Quick Assist code, and alert on every execution. - Constrain MSI installation. Block
msiexecfrom installing packages sourced from the internet or user-writable paths via AppLocker/WDAC policy, and alert on MSI installations outside your software deployment platform. - Hunt retroactively. Run the KQL and VQL hunts above across at least 30 days of telemetry. Any ScreenConnect-spawned script host execution is an IR trigger: isolate the host, capture the script artifacts before cleanup, and identify every host that received a connection from the rogue client — the worm-like propagation means patient zero is almost never the only victim.
- Incident response for confirmed cases. Treat each newly connected host as potentially compromised. Pull the full session recording/logs from ScreenConnect, acquire the staged
.vbs/.vbefiles for analysis, and check downstream child processes for credential access and C2. Reset credentials for any account used interactively during rogue sessions.
The Bottom Line
This campaign is a textbook example of why RMM governance is now a frontline security control. The attackers didn't need a zero-day — they needed a signed, trusted remote access binary and a script interpreter that ships with Windows. Organizations that allow unmanaged RMM tooling, leave Windows Script Host enabled by default, and treat Quick Assist as harmless are presenting exactly the attack surface these actors are exploiting. Close those three gaps and this technique dies on the vine.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.