ScreenConnect Appears Across Unrelated Hosts in Suspected Worm-Like Activity

Summary

Threat actors are deploying rogue ScreenConnect instances that display worm-like behavior to spread across connected systems. After a machine is compromised, the modified ScreenConnect client automatically transfers and executes a multi-stage VBScript chain on newly connected endpoints. The campaign combines social engineering and RMM abuse to maintain persistence and deliver additional payloads, including credential stealers and cryptocurrency miners.

Investigation

Huntress identified suspicious process activity in which ScreenConnect clients spawned wscript.exe to execute a sequence of VBScript files named 1.vbs through 4.vbs. Analysis showed that the scripts profile infected systems, check for EDR products, and retrieve staged payloads from Dropbox. Modified ScreenConnect clients were then used to propagate the scripts to newly connected hosts.

Mitigation

Administrators should closely monitor on-premises ScreenConnect deployments and review audit logs for anomalous activity. In particular, defenders should look for RunFiles or RanFiles entries associated with the identified VBScript filenames executed from the Guest process. Organizations should also enforce strict controls over RMM tools and remote support utilities such as Quick Assist.

Response

Affected hosts should be reimaged using known-good media or restored through a clean operating system installation. Security teams should immediately review ScreenConnect audit logs for evidence of suspicious script execution. Any abnormal wscript.exe or PowerShell activity occurring after an RMM connection should also be treated as a high-priority security incident.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre-flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands: An adversary has gained initial access to a workstation. To evade detection by basic EDR rules that monitor for direct powershell.exe execution, they drop a VBScript file that leverages the built-in Windows Script Host. The VBScript is designed to execute a secondary PowerShell script named runner.ps1. This script is intended to load a credential dumping module into memory. By using wscript.exe as the parent, the attacker attempts to blend in with standard Windows administrative activity.

• Regression Test Script:

  # Create a dummy 'runner.ps1' file to satisfy the detection logic's string requirement
  $dummyScript = "$PSScriptRootrunner.ps1"
  New-Item -Path $dummyScript -ItemType File -Force
  Set-Content -Path $dummyScript -Value "Write-Host 'Simulating Payload Execution'"
  
  # Create a VBScript that calls the PowerShell script
  # This mimics the attacker's method of using WSH to launch PowerShell
  $vbsContent = @"
  Set objShell = CreateObject("WScript.Shell")
  objShell.Run "powershell.exe -ExecutionPolicy Bypass -File ""$dummyScript""", 0, True
  "@
  $vbsFile = "$PSScriptRootlauncher.vbs"
  Set-Content -Path $vbsFile -Value $vbsContent
  
  # Execute the VBScript via wscript.exe to trigger the detection rule
  Write-Host "[!] Executing simulation via wscript.exe..."
  Start-Process "wscript.exe" -ArgumentList "`"$vbsFile`""

• Cleanup Commands:

  # Remove the simulation artifacts
  Remove-Item -Path "$PSScriptRootrunner.ps1" -ErrorAction SilentlyContinue
  Remove-Item -Path "$PSScriptRootlauncher.vbs" -ErrorAction SilentlyContinue
  Write-Host "[+] Cleanup complete."