Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts

1. Executive summary

Huntress has disclosed worm-like activity in which backdoored ConnectWise ScreenConnect clients distribute a four-stage VBScript chain to newly connected hosts, observed across three unrelated incidents in August 2026. Initial access was achieved through three distinct vectors — a Quick Assist tech-support scam, a phishing-delivered MSI installer, and a fake Geek Squad refund form lure — converging on the same payload chain, which profiles the host, checks for security products, and deploys one of at least three payloads: a user-level ScreenConnect backdoor, UAC-bypass privilege-escalation tooling with persistence, or tunnelling utilities plus a cryptocurrency miner. No CVE is involved; this is a social-engineering and malicious-software-distribution campaign, not a product vulnerability, and ConnectWise ScreenConnect is being abused as a legitimate remote-access tool rather than exploited. No verified reference data resolved for this item, so no CVSS or CISA-KEV states apply. EMEA financial services firms should treat unsolicited remote-support contact and any ScreenConnect client appearing outside standard software deployment channels as high-priority compromise signals.

2. Regulatory framing

No NIS2 or UK NIS article is cited here: the reference scopes (NIS2 Art. 21(2)(d) supply chain security measures, NIS2 Art. 23 incident reporting, UK NIS 2018 OES/RDSP duties) are not specifically triggered by facts distinctive to this item beyond what any malware incident would engage.

3. Technical analysis & attack chain

Confirmed attack chain (per Huntress, corroborated in summary by SecurityWeek)

1. Initial access via one of three observed vectors: (a) a tech-support scam persuading the user to run Windows Quick Assist; (b) a phishing-delivered MSI installer, ScreenConnect.ClientSetup.msi; (c) a user searching for a Geek Squad refund form and receiving a rogue client binary, ScreenConnect.Client.exe.
2. Rogue ScreenConnect deployment. The malicious client is installed and connects to attacker infrastructure: 45.13.237[.]190 (tele-sync.opik[.]net), 131.123.40[.]98 on port 8041, or borertors92.anondns[.]net, depending on the incident.
3. Worm-like propagation. The backdoored ScreenConnect instance repeatedly spawns wscript.exe to execute four VBScripts — 1.vbs, 2.vbs, 3.vbs, 4.vbs — from the ScreenConnect temporary directory or the Temp folder, transferring the chain to newly connected systems.
4. Host profiling (1.vbs). Checks system resources (e.g., RAM over 5 GB), verifies whether ScreenConnect is installed, enumerates running security products — specifically Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, and Symantec Endpoint Protection — and writes a three-bit state variable to %TEMP%\value.txt. State 000 indicates no existing ScreenConnect installation, third-party security processes present, and no ScreenConnect clients in Program Files.
5. Staged download (2.vbs). Waits for %TEMP%\value.txt, aborts if the word "abort" is present, otherwise downloads a file from Dropbox, decodes it, and writes the result to %TEMP%\map.txt. The retrieved content is not executed; the exact nature of this stage is unclear because the Dropbox URL was offline as of 2026-09-02.
6. Payload retrieval (3.vbs). Waits for %TEMP%\map.txt, then downloads the file specified at the Dropbox link recorded there, selected according to the state value in %TEMP%\value.txt, and writes it to %TEMP%\out.enc.
7. Decryption and execution (4.vbs). Waits for %TEMP%\out.enc, launches %TEMP%\runner.ps1 to decrypt it, writes the result to %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip, and executes a second-stage PowerShell script, PyTorchFix.ps1.
8. Cleanup. runner.ps1 terminates every wscript.exe and cscript.exe process and deletes the staging directory after the final stage runs. The source text is truncated mid-path when describing 4.vbs writing the four VBScript files to C:\Users\P...; the full destination path is not available in the provided material.

Payload selection by state value (at least three variants)

• 000 and 001 → user-level ScreenConnect backdoor
• 010 → privilege-escalation tooling via a UAC bypass, plus persistence
• 011 → tunnelling utilities and a cryptocurrency miner

Defender-relevant specifics: the chain is EDR-aware — the security-product enumeration in stage 1 feeds payload selection, so the same initial access can yield different post-exploitation behaviour per host. Persistence is established through the rogue ScreenConnect client itself plus, for the 010 path, additional persistence tooling; the sys_cache.zip path under %APPDATA%\Microsoft\Windows\Templates\Classic\ is a deliberate masquerade into a legitimate-looking Microsoft directory. C2 is layered: direct IP (45.13.237[.]190), IP-with-port (131.123.40[.]98:8041), and dynamic-DNS style hostname (borertors92.anondns[.]net), with Dropbox used as a staging intermediary for payload delivery.

Confidence caveats: The full technical detail — file names, paths, state-variable logic, payload matrix — is single-sourced from the Huntress research as reported by The Hacker News; SecurityWeek corroborates the campaign's existence and mechanism (backdoored ScreenConnect instances transferring and executing payloads to newly connected clients) but not the stage-by-stage detail. Verify before enforcement. No threat-actor attribution is present in the source material, and no verified reference data resolved for this item, so no attribution or CVSS/KEV statements are made. The nature of the stage-2 Dropbox payload is explicitly unknown to the researchers.

4. Mitigation & containment

P1 — within 24 hours

• Hunt for the chain across the estate: wscript.exe executions of files named 1.vbs–4.vbs, PowerShell spawning from %TEMP%\runner.ps1 or PyTorchFix.ps1, and any file at %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip. Isolate any positive hosts.
• Block the three C2 endpoints at egress: 45.13.237[.]190, 131.123.40[.]98 (all ports, including 8041), and borertors92.anondns[.]net / anondns[.]net resolution.
• Review ScreenConnect (or any ConnectWise remote-access) deployments: enumerate installed clients and confirm each connects only to organisation-owned, expected server endpoints. Any client contacting the IPs/domains above is a rogue installation — remove it and rebuild the host.
• If Quick Assist is not required for support workflows, disable it via policy (Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WinRM" ... is not applicable; use the Windows Defender Attack Surface Reduction rule or uninstall the Quick Assist app package) pending P2 review.

P2 — within 72 hours

• Restrict script interpreters: enforce ASR rules or application control to block wscript.exe/cscript.exe execution of user-writable VBScript, and constrain PowerShell to Constrained Language Mode or script-block logging with transcription.
• Block user-writable Dropbox fetches from endpoints where not business-required, or at minimum alert on powershell.exe/wscript.exe downloading from Dropbox URLs.
• Reinforce helpdesk-impersonation awareness: the Quick Assist and Geek Squad refund lures are social engineering against the user, not against a vulnerability. Instruct staff that legitimate support will never initiate contact asking them to run Quick Assist or install remote-access software.
• Verify that EDR coverage includes the products the chain enumerates (Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, Symantec SEP) and that the 000-state logic — which implies payload selection adapts to security-tool presence — is understood by the SOC: absence of an expected security process is itself a signal.

P3 — within 7 days

• Audit remote-access tooling governance: whitelist permitted remote-support tools, block all others at the endpoint, and require change-control approval for any ScreenConnect client installation.
• Review Temp-folder and %APPDATA% write-and-execute paths against application-control policy; the chain executes entirely from user-writable locations.
• Confirm no persistence remnants: check for unexpected ScreenConnect services/clients, scheduled tasks, and the Classic\Templates directory contents on any host that matched P1 hunting.

No vendor fix applies — this is not a vulnerability in ScreenConnect; the remediation is detection, removal of rogue clients, and process controls.

5. Indicators of compromise

ipv4  45.13.237[.]190
domain  tele-sync.opik[.]net
ipv4  131.123.40[.]98
domain  borertors92.anondns[.]net
filename  ScreenConnect.ClientSetup.msi
filename  ScreenConnect.Client.exe
filename  1.vbs
filename  2.vbs
filename  3.vbs
filename  4.vbs
filepath  %TEMP%\value.txt
filepath  %TEMP%\map.txt
filepath  %TEMP%\out.enc
filepath  %TEMP%\runner.ps1
filepath  %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip
filename  PyTorchFix.ps1

No file hashes are present in the source material. The IOC set is single-sourced from the Huntress research; verify before enforcement.

6. Detection

rule Rogue_ScreenConnect_VBScript_Chain_Stage4 {
    meta:
        author = "Adverse Trace"
        date = "2026-09-07"
        reference = "https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html"
        description = "Detects stage-4 VBScript / runner.ps1 artefacts from the rogue ScreenConnect four-stage chain (sys_cache.zip drop path and PyTorchFix.ps1 second stage)"
    strings:
        $zip_path = "Microsoft\\Windows\\Templates\\Classic\\sys_cache.zip" ascii
        $runner = "runner.ps1" ascii
        $pytorch = "PyTorchFix.ps1" ascii
        $outenc = "out.enc" ascii
    condition:
        all of them
}

rule Rogue_ScreenConnect_VBScript_Chain_Staging {
    meta:
        author = "Adverse Trace"
        date = "2026-09-07"
        reference = "https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html"
        description = "Detects staging artefacts of the rogue ScreenConnect chain (value.txt state file, map.txt decoded stage, abort check)"
    strings:
        $value = "value.txt" ascii
        $map = "map.txt" ascii
        $abort = "abort" ascii
    condition:
        all of them
}

title: Rogue ScreenConnect Client Spawning VBScript Chain via wscript.exe
id: 7a2f1c44-09b7-4e2a-9f6d-772a0b5c8e11
status: experimental
description: Detects wscript.exe executing the four-stage VBScript chain (1.vbs-4.vbs) associated with rogue ScreenConnect clients, per Huntress reporting of August 2026 incidents.
references:

    - https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
author: Adverse Trace
date: 2026/09/07
logsource:
    category: process_creation
    product: windows
detection:
    selection_script:
        Image|endswith: '\wscript.exe'
        CommandLine|contains:

            - '1.vbs'
            - '2.vbs'
            - '3.vbs'
            - '4.vbs'
    condition: selection_script
falsepositives:

    - Legitimate VBScript deployments using single-digit filenames (unlikely in managed environments)
level: high

title: PowerShell Execution of runner.ps1 or PyTorchFix.ps1 from Temp
id: 3d8b5e92-41c6-4f7b-a1d9-8830c4e6f2b7
status: experimental
description: Detects execution of the rogue ScreenConnect chain's PowerShell stages (runner.ps1 decryptor, PyTorchFix.ps1 second stage) from user-writable paths.
references:

    - https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
author: Adverse Trace
date: 2026/09/07
logsource:
    category: process_creation
    product: windows
detection:
    selection_runner:
        CommandLine|contains:

            - 'runner.ps1'
            - 'PyTorchFix.ps1'
    condition: selection_runner
falsepositives:

    - None expected; filenames are highly specific to this chain
level: critical

7. Sources

• The Hacker News — "Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts" — https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html — 2026-09-07
• SecurityWeek — "Modified ScreenConnect Clients Used in Worm-Like Campaign" — https://www.securityweek.com/modified-screenconnect-clients-used-in-worm-like-campaign/ — 2026-09 (corroborates campaign existence and mechanism; no additional technical detail)

8. Adverse Trace position

This is a credible, technically detailed campaign report from Huntress, but the stage-by-stage detail is single-sourced and should be verified before enforcement action; SecurityWeek corroborates the overall mechanism only. Severity for EMEA financial services is high where remote-support social engineering reaches users: the chain is EDR-aware, adapts payload selection to the victim's security stack, establishes persistence through a legitimate remote-access client, and can deliver tunnelling tooling — a direct prelude to fraud-enabled access on transaction systems — alongside a cryptominer. No CVE, CVSS, or CISA-KEV state applies, and no attribution is claimed in the source material; treat attribution as unconfirmed. We will monitor for the stage-2 Dropbox payload's nature, additional C2 infrastructure, and any follow-on reporting that corroborates the IOC set, and will reissue this advisory if hashes or a second independent technical source emerges.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.