ROGUE SCREENCONNECT INSTALLATIONS ACROSS UNRELATED HOSTS SUGGEST WORM-LIKE ACTIVITY

Summary from the TLDR InfoSec newsletter

Modified ScreenConnect clients recovered by Huntress watch the EndPointStatusMessage.Connections collection for newly observed Host sessions, then register 1.vbs through 4.vbs with ScreenConnect's virtual file-transfer system and queue them with the action set to Run, so merely connecting to an infected client can hand the Host the same four-stage VBScript chain. The loader profiles first: 1.vbs writes a three-bit state to %TEMP%\value.txt covering existing ScreenConnect installs, whether Defender is the only endpoint protection present, and whether RAM exceeds 5GB, and that value selects a user-level backdoor, an access package with a ComputerDefaults.exe UAC bypass and AMSI tampering, or a combo branch carrying wstunnel disguised as Themes.exe and XMRig renamed SearchIndex.exe. Defenders should treat RunFiles or RanFiles entries in ScreenConnect server audit logs showing those scripts executed from Process: Guest as indicators of compromise, check for the WindowsServiceHost Run key pointing at WindowsServiceHost.vbs in AppData, and note that Huntress recommends reimaging affected hosts rather than cleaning them.