What happened
Huntress investigated separate social-engineering incidents on 20 August 2026 involving rogue ScreenConnect clients and the same four VBScript files. Huntress observed the same behaviour again on 24 August 2026 after a victim executed a rogue ScreenConnect client. Initial access included abuse of Microsoft Quick Assist, phishing and a fake Geek Squad refund workflow. Huntress observed ScreenConnect.WindowsClient.exe repeatedly spawning wscript.exe to execute 1.vbs, 2.vbs, 3.vbs and 4.vbs. The campaign created a WindowsServiceHost User Run Key pointing to WindowsServiceHost.vbs in the user’s AppData directory.
Payload analysis showed scripts profiling installed security tools, staging encrypted packages and launching PowerShell with an execution-policy bypass. One recovered access package installed concealed ScreenConnect client ID 7a4d7d66502d4260 and staged scripts under C:\Users\Public\Libraries\Default\Lib\Lib1. Modified clients inspected new ScreenConnect host connections and used the platform’s virtual file-transfer mechanism to queue the script chain for execution. Huntress observed ScreenConnect connections involving 45.13.237.190, 131.123.40.98 and 15.204.185.204, with one client using port 8041.
ConnectWise published its interim ScreenConnect file-transfer advisory on 3 September 2026. ConnectWise advises administrators to disable TransferFiles, or TransferFilesInSession on legacy versions, until its official fix is available. SecurityWeek brought the campaign and the still-open vendor advisory together in reporting published on 7 September 2026. ConnectWise says a CVE and official fix are pending, but its public advisory does not state that the issue caused these incidents. Attribution posture: Huntress describes the operator only as a threat actor and establishes no named-group attribution.
Why this matters now
Remote-management software is already privileged by design. The campaign turns that trust into a propagation path: a socially engineered endpoint receives a modified client, and later ScreenConnect connections can cause scripts to execute on additional systems. That undermines assumptions that containment of the first user device or removal of an initial remote-support session ends the incident. Any connected technician or host workflow may extend the affected set.
The vendor advisory and the observed campaign must be handled together but not conflated. ConnectWise acknowledges a file-transfer behaviour issue and supplies an interim permission change; it does not publicly attribute the campaign to that defect or confirm that its own service was compromised. Security leaders should apply the mitigation because it reduces an unnecessary execution path, while preserving a separate investigation into rogue clients, social engineering, relay destinations and affected endpoints.
The decision for security leaders
Treat remote-management infrastructure as a privileged control plane. Reconcile cloud tenants, on-premises servers, client identifiers, technician roles, session groups and relay destinations under one accountable owner. Any unidentified instance or relay should be disabled or isolated until its provenance is established. Include MSP and outsourced support arrangements in the inventory.
Apply the ConnectWise permission mitigation while testing its operational impact on support workflows. The change reduces file-transfer exposure but does not remove already modified clients or persistence. Require endpoint hunts across every system that connected to a suspect client, and rebuild hosts where script execution, concealment, mining, tunnelling or security-control modification is established.
Evidence of closure
- ScreenConnect inventory reconciles every server, client, owner and relay destination.
- Role exports confirm file transfer is disabled unless explicitly approved.
- Endpoint hunts return no matches for the scripts, run key, client ID or IP addresses.
- Rebuilt endpoints reconnect only to approved ScreenConnect infrastructure.
The Security.io assessment
The strongest evidence concerns a campaign that begins with social engineering and then mechanically abuses modified ScreenConnect clients to propagate scripts. The available sources do not establish exploitation of a named CVE, compromise of ConnectWise’s environment or a named actor. Confidence is therefore medium: the behaviour and artefacts are well documented, but the relationship between the campaign and the vendor’s file-transfer issue remains unresolved.
The executive lesson is broader than one RMM product. Remote-support software creates a trusted cross-endpoint execution channel that can outlive the initial scam and invalidate host-by-host containment assumptions. Organisations need an emergency disable path, complete client and relay inventory, narrowly scoped technician permissions and telemetry capable of showing which files were transferred or run through each session.
Questions for the morning meeting
- Where are approved and unauthorised ScreenConnect servers and clients operating?
- Which roles retain file-transfer permissions across cloud and on-premises instances?
- Can endpoint teams distinguish approved ScreenConnect relays from attacker-controlled infrastructure?
- Who can immediately disable a compromised remote-management trust path?