Abuso simile a un worm di ScreenConnect diffonde VBScript su nuovi host

I ricercatori di sicurezza di Huntress hanno pubblicato dettagli su un abuso simile a un worm di ConnectWise ScreenConnect, uno strumento di accesso remoto ampiamente utilizzato, in cui client malintenzionati consegnano una catena VBScript in quattro fasi a sistemi appena connessi. L'azienda ha osservato tre incidenti non correlati nell'agosto 2026 che sono iniziati con diverse esche: una truffa di supporto tecnico Quick Assist, un installer MSI distribuito tramite phishing e una ricerca di un modulo di rimborso falso di Geek Squad. Ciascuno alla fine ha installato un client ScreenConnect malintenzionato che ha ripetutamente avviato wscript.exe per eseguire quattro script denominati 1.vbs, 2.vbs, 3.vbs e 4.vbs.

I quattro script formano una sequenza di infezione a fasi. In primo luogo, 1.vbs profila la macchina vittima: controlla se il sistema ha più di 5 GB di RAM, verifica se ScreenConnect è già installato ed elenca i prodotti di sicurezza tra cui Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos e Symantec Endpoint Protection. I risultati vengono scritti in %TEMP%\value.txt come valore di stato a tre bit. Huntress spiega che uno stato di 000, ad esempio, significa nessuna installazione ScreenConnect esistente, processi di sicurezza di terze parti presenti e nessun client ScreenConnect installato in Program Files. Successivamente, 2.vbs attende value.txt e cerca la parola abort. Se la parola non è presente, scarica un file da un link Dropbox, decodifica il contenuto e lo scrive in %TEMP%\map.txt. Il contenuto di quel file di testo non viene eseguito e la natura esatta dei dati scaricati non è chiara perché l'URL di Dropbox era già offline a partire dal 2 settembre 2026. Lo script 3.vbs attende quindi map.txt, scarica il file nominato in quel file di testo in base al valore di stato e lo salva come %TEMP%\out.enc. Infine, 4.vbs attende out.enc, avvia uno script PowerShell in %TEMP%\runner.ps1 per decrittare il contenuto, scrive il risultato in %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip e quindi esegue uno script PowerShell di seconda fase chiamato PyTorchFix.ps1.

I tre incidenti osservati mostrano come la stessa catena sia stata consegnata attraverso diversi punti di ingresso. Nel primo, un utente è stato convinto durante una truffa di supporto tecnico a eseguire Quick Assist, dopo di che un client di accesso remoto ScreenConnect malintenzionato ha contattato un server di comando e controllo all'indirizzo 45.13.237[.]190, noto anche come tele-sync.opik[.]net; quel server ospitava un archivio RAR contenente i quattro file VBS. Nel secondo, un installer MSI denominato ScreenConnect.ClientSetup.msi, probabilmente inviato tramite phishing, ha distribuito un client configurato per raggiungere 131.123.40[.]98 sulla porta 8041, e il client ha quasi immediatamente eseguito i quattro script dalla directory temporanea di ScreenConnect. Nel terzo, una ricerca di un modulo di rimborso Geek Squad ha portato a un eseguibile malintenzionato denominato ScreenConnect.Client.exe che si è connesso a borertors92.anondns[.]net e poi ha utilizzato wscript.exe per eseguire gli stessi script dalla cartella Temp.

A seconda del valore di stato a tre bit, la catena seleziona diversi payload. Gli stati 000 e 001 risultano in una backdoor ScreenConnect a livello utente. Lo stato 010 porta a strumenti per l'escalation dei privilegi tramite un bypass del Controllo account utente e meccanismi di persistenza. Lo stato 011, che Huntress dice significa che la macchina non ha installazione ScreenConnect esistente, solo Microsoft Defender come protezione degli endpoint e nessun client ScreenConnect presente, porta a utilità di tunneling e a un miner di criptovaluta XMRig. I payload dello stato 011 disabilitano anche la segnalazione di Microsoft Defender e disattivano l'integrità della memoria di Windows. Inoltre, lo script runner.ps1 termina ogni processo wscript.exe o cscript.exe ed elimina la directory di staging dopo la fase finale. Se value.txt è impostato su 010 o 011, lo script 4.vbs copia anche i quattro file VBScript in C:\Users\Public\Libraries\Default\Lib\Lib1, il che aiuta l'infezione a sopravvivere e diffondersi.

Huntress descrive il risultato come comportamento simile a un worm. Ogni volta che un client ScreenConnect infetto osserva una nuova connessione Host, innesca un altro giro di consegna di payload, trasformando la macchina compromessa in un meccanismo di distribuzione di contenuti per gli script. La connessione a un client infetto può causare la ricezione e l'esecuzione della stessa catena VBScript in quattro fasi da parte del sistema Host lato server. Il client registra ogni ConnectionID in modo da non prendere di mira ripetutamente la stessa sessione attiva, ma rimuove tale identificatore dopo la disconnessione della sessione, consentendo a una successiva riconnessione di innescare nuovamente l'infezione. Huntress ha anche trovato una chiave di esecuzione condivisa denominata WindowsServiceHost nel profilo utente che punta a WindowsServiceHost.vbs nella directory AppData, e su alcune macchine colpite ha osservato altri strumenti di monitoraggio e gestione remota come UltraViewer. A causa della complessità di queste catene, il SOC di Huntress raccomanda vivamente di reinstallare gli host colpiti da supporti noti e puliti o di eseguire una pulita installazione del sistema operativo.

ConnectWise ha emesso un avviso in risposta ai risultati. L'azienda afferma di aver identificato un problema che influisce sul comportamento del trasferimento file nelle sessioni di ScreenConnect Remote Access Support e Access, e il problema influisce sia sulle distribuzioni cloud che on-premise. Fino a quando non sarà disponibile una correzione, ConnectWise raccomanda agli amministratori di disabilitare la capacità dei tecnici di trasferire file. Ciò comporta l'accesso alla pagina di amministrazione di ScreenConnect, andando su Amministrazione > Sicurezza > Ruoli, modificando ogni ruolo assegnato, rivedendo le autorizzazioni con ambito per ogni gruppo di sessioni e deselezionando l'autorizzazione TransferFiles (o TransferFIlesInSession nelle versioni legacy) dove è selezionata, quindi salvando le modifiche per ogni ruolo.

Per i team che gestiscono strumenti di accesso remoto e supporto, AEU-I offre consulenza IT e infrastrutturale incentrata sulla sicurezza che può aiutare a rivedere ruoli di accesso, autorizzazioni e configurazioni di supporto remoto prima che diventino parte di un attacco come questo.