As reported by The Hacker News, researchers at Huntress have documented a worm-like abuse pattern targeting ConnectWise ScreenConnect, where rogue client instances execute a staged VBScript payload chain against every newly connected host. Three distinct initial access vectors — a Quick Assist tech-support scam, a phishing-delivered MSI installer, and a fake Geek Squad refund lure — all converged on the same post-compromise behavior: a ScreenConnect client repeatedly spawning wscript.exe to execute sequentially named scripts (1.vbs through 4.vbs) from its temporary directory.

Threat Alert: Three distinct initial access vectors — a Quick Assist tech-support scam, a phishing-delivered MSI installer, and a fake Geek Squad refund lure — all converged on the same post-compromise behavior: a ScreenConnect client repeatedly spawning wscript.exe to execute sequentially named scripts (1.vbs through 4.vbs) from its temporary directory.

Why This Matters

This campaign is a textbook example of living-off-the-land abuse taken to its next logical step. The attackers are not exploiting a vulnerability in ScreenConnect itself — they are weaponizing the tool's intended functionality. ScreenConnect is designed to execute commands and transfer files to connected endpoints. Once a rogue client is installed, every system it touches becomes a propagation node. The worm-like behavior means a single social engineering success can cascade across an organization's endpoint fleet.

What elevates this beyond routine RAT deployment is the EDR-aware staging logic in the first-stage script. The malware explicitly enumerates a who's-who of endpoint protection vendors — Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, and Symantec — and encodes the results as a three-bit state variable before deciding how to proceed. This is not opportunistic scripting; it is conditional execution designed to adapt to the defender's posture on each individual host.

Who Is Affected

Why This Matters
MSPs and IT support providers using ScreenConnect or similar RMM tools (AnyDesk, TeamViewer, BeyondTrust) — these organizations are both targets and inadvertent propagation vectors
SMB environments where tech-support scam lures are most effective and endpoint monitoring may be less mature
Organizations with permissive script execution policies — the entire chain relies on wscript.exe being able to run VBScript from temp directories without restriction
Help desk and support teams whose workflows involve Quick Assist or remote support sessions — the social engineering entry points directly target these personas

Broader Implications

The convergence of three unrelated initial access vectors into an identical post-compromise chain suggests a shared toolkit or affiliate model behind this campaign. The attackers are distributing the entry-point work across multiple social engineering playbooks while standardizing the payload delivery mechanism.

This pattern mirrors what we have observed with other RMM-tool abuse campaigns over the past 18 months — threat actors increasingly prefer legitimate remote management software over custom malware because it blends into normal administrative traffic, persists across reboots, and is rarely blocked by default EDR policies. The use of Dropbox as a staging channel in stage 2 further reinforces the cloud-service-as-C2 trend, making traffic-based detection significantly harder.

For defenders, the most concerning tactical detail is the value.txt state machine. If the word "abort" appears in that file, the chain halts. This implies the attackers built in a kill-switch conditioned on environment checks — and it also means defenders have a detection artifact that exists on every compromised host, even if later stages were prevented from executing.

Shield53 Recommendations

Immediate Actions

  • Hunt for IOCs: Search endpoints for %TEMP%\value.txt, %TEMP%\map.txt, and VBScript files named 1.vbs through 4.vbs in ScreenConnect temp directories. Any presence indicates attempted or successful compromise.
  • Block known C2 infrastructure: Add the reported indicators — 45.13.237.190, tele-sync.opik.net, 131.123.40.98:8041, borertors92.anondns.net — to network and DNS blocklists. Monitor for any outbound connections to these destinations.
  • Audit ScreenConnect deployments: Inventory all ScreenConnect clients across the environment. Verify each connects only to known, approved server instances. Rogue clients connecting to unknown hosts are the primary indicator of compromise.
  • Restrict script execution: Enable Windows Script Host (WSH) restrictions via AppLocker or WDAC. At minimum, disable wscript.exe execution from temp and user-writable directories. This single control would break the entire described chain.

Strategic Hardening

  • RMM governance: Implement an allowlist approach for remote management tools. Any RMM software not on the approved list should trigger automated alerting and isolation.
  • Attack surface reduction: Deploy ASR rules, specifically the rule blocking obfuscated JS/VBS/PS code and the rule blocking execution of VBScript from email/client apps.
  • Help desk awareness: Brief support teams on the Quick Assist and Geek Squad refund lures. The initial access vectors in all three incidents relied on social engineering — technical controls alone will not stop the entry point.
  • Monitor for child process anomalies: ScreenConnect spawning wscript.exe is not normal administrative behavior. Create detection rules for this parent-child relationship across all RMM tools in your environment.

The takeaway for security leaders is straightforward: remote management tools are dual-use infrastructure. Every RMM agent on your network is a potential foothold, and the threat landscape has matured to the point where attackers expect to find them and know exactly how to abuse them. Treating RMM software with the same governance rigor as any other privileged access pathway is no longer optional.