> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts - URL: https://f4n6.co.uk/security-feed/rogue-screenconnect-clients-spread-four-stage-vbscript-chain-to-newly-connected-hosts/ - Published: 2026-09-07T16:42:20.000Z - Updated: 2026-09-07T16:42:20.000Z - Author: Jeff Davies - Tags: #security-feed ## 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 | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 18: classification of ICT-related incidents and cyber threats | The campaign is a live, named cyber threat (worm-like distribution of backdoored ScreenConnect clients) that firms must classify under their incident taxonomy; the three distinct initial-access vectors mean a single infection may surface as a social-engineering report rather than a malware incident | Ensure classification criteria capture remote-access-tool abuse and social-engineering-delivered malware so these events are not mis-filed as low-severity user reports | | DORA Art. 19: reporting of major ICT-related incidents to competent authorities | A successful ScreenConnect backdoor with privilege-escalation or tunnelling payloads on a financial-services host plausibly meets major-incident thresholds (unauthorised access, potential persistence) | If infection is confirmed on an in-scope host, assess against major-incident criteria and prepare notification rather than handling as an isolated endpoint cleanup | 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 | Type | Value | Confidence | Source | | -------- | ----------------------------------------------------------------- | ---------- | ---------------------------- | | ipv4 | 45.13.237\[.\]190 | High | Huntress via The Hacker News | | domain | tele-sync.opik\[.\]net | High | Huntress via The Hacker News | | ipv4 | 131.123.40\[.\]98 | High | Huntress via The Hacker News | | domain | borertors92.anondns\[.\]net | High | Huntress via The Hacker News | | filename | ScreenConnect.ClientSetup.msi | High | Huntress via The Hacker News | | filename | ScreenConnect.Client.exe | High | Huntress via The Hacker News | | filename | 1.vbs | High | Huntress via The Hacker News | | filename | 2.vbs | High | Huntress via The Hacker News | | filename | 3.vbs | High | Huntress via The Hacker News | | filename | 4.vbs | High | Huntress via The Hacker News | | filepath | %TEMP%\\value.txt | High | Huntress via The Hacker News | | filepath | %TEMP%\\map.txt | High | Huntress via The Hacker News | | filepath | %TEMP%\\out.enc | High | Huntress via The Hacker News | | filepath | %TEMP%\\runner.ps1 | High | Huntress via The Hacker News | | filepath | %APPDATA%\\Microsoft\\Windows\\Templates\\Classic\\sys\_cache.zip | High | Huntress via The Hacker News | | filename | PyTorchFix.ps1 | High | Huntress via The Hacker News | ```iocs 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 ```yara 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 } ``` ```yaml 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 ``` ```yaml 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 →](https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*