August produced three attacks with different lures but a single nasty ending: a rogue ScreenConnect client that pushed a four-stage VBScript chain onto every new host that connected to it. Huntress researchers documented all three and warn the pattern spreads like a worm.
The front doors could hardly differ more. One victim was talked into running Quick Assist during a tech-support scam, another installed a phishing-delivered MSI, and a third went looking for a Geek Squad refund form. Each machine ended up running a ScreenConnect client pointing at attacker infrastructure, and each client started spawning wscript.exe to run scripts named 1.vbs through 4.vbs.
Script one maps the box: memory size, endpoint products present, and whether ScreenConnect already exists, stored as a three-bit state. Script two waits for that state and pulls a config file from Dropbox. Script three downloads the payload the state calls for, and script four decrypts it and passes execution to PowerShell. Outcomes branch on those bits: a user-level backdoor, UAC-bypass and persistence gear, or tunneling tools paired with an XMRig miner. One branch also silences Microsoft Defender reporting and turns off Windows memory integrity.
What makes the campaign spread is the client’s own behavior. Each time a fresh Host joins an infected instance, the chain replays against that system. Huntress says the client logs connection IDs so it does not re-hit the same session, then clears them at disconnect, which means a later reconnection starts the cycle over.
ConnectWise’s advisory lands on the tool’s own file transfer handling, which the vendor says misbehaves during Remote Access Support and Access sessions for cloud and on-premise installs alike. While a fix is prepared, admins should strip the TransferFiles permission from technician roles. Huntress goes further, recommending that affected hosts be reimaged from known-good media.
