ScreenConnect weaponizzato: malware in auto-propagazione via file transfer

Il 3 settembre 2026 Huntress ha reso pubblica una campagna di attacco che trasforma ConnectWise ScreenConnect da strumento di remote support a vettore di propagazione automatica. Client modificati, distribuiti inizialmente tramite ingegneria sociale, sfruttano la funzione di file transfer virtuale per replicarsi su ogni nuovo endpoint che si connette alla sessione, generando una diffusione worm-like che non richiede ulteriore interazione umana dopo il primo compromesso.

Come funziona la catena di infezione a 4 stadi

La meccanica di attacco documentata da Huntress si articola in quattro file VBScript eseguiti in sequenza. Il primo, 1.vbs, effettua il profiling della macchina bersaglio: verifica se ScreenConnect è già installato, misura la RAM disponibile e rileva la presenza di prodotti EDR specifici tra cui Huntress stesso, Cisco AMP, CrowdStrike, SentinelOne, Sophos e Malwarebytes. Queste informazioni vengono codificate in un valore di stato a tre bit che determina quale payload verrà successivamente recuperato.

Il secondo stadio, 2.vbs, si connette a Dropbox per scaricare un file di configurazione offuscato con Base64 e XOR. La decodifica produce una mappa che associa ciascun valore di stato a un URL cifrato e alla corrispondente chiave AES per il recupero del payload. Il terzo script, 3.vbs, utilizza questa mappa per scaricare l'archivio cifrato appropriato e salvarlo come out.enc nella directory temporanea.

Il quarto e ultimo file, 4.vbs, scrive e lancia runner.ps1 con execution-policy bypass. Lo script PowerShell decripta out.enc utilizzando AES-CBC, estrae il contenuto ZIP ed esegue PyTorchFix.ps1, completando il deployment del payload finale sulla macchina compromessa.

La persistenza e i tre outcome documentati

La catena VBScript stabilisce persistenza attraverso una chiave di registro Run Key denominata WindowsServiceHost, che punta a WindowsServiceHost.vbs nella cartella AppData dell'utente. Questo meccanismo garantisce il riavvio automatico della catena malware ad ogni accesso alla sessione.

Huntress ha catalogato tre outcome distinti del payload finale, selezionati in base al profiling iniziale. Il primo è una backdoor a livello utente all'interno dello stesso ScreenConnect. Il secondo, definito "access package", include strumenti di persistenza avanzata e privilege escalation: GBHackers documenta l'utilizzo di un bypass UAC che sfrutta l'hijacking del protocol handler ms-settings: e l'eseguibile ComputerDefaults.exe per elevare privilegi senza richiesta di consenso.

Il terzo outcome combina componenti di tunneling di rete e cryptomining. I ricercatori hanno identificato wstunnel mascherato come Themes.exe, XMRig rinominato SearchIndex.exe e il driver vulnerabile WinRing0, utilizzato per accedere direttamente all'hardware e massimizzare l'efficienza del mining. Questa stratificazione consente agli attaccanti di scegliere tra accesso occulto, escalation locale o monetizzazione immediata in base al profilo della vittima.

Infrastruttura C2 e indicatori di compromissione

L'analisi di Huntress ha esposto un'infrastruttura di comando e controllo distribuita su più indirizzi IP e domini. Gli indicatori documentati includono gli IP 45.13.237[.]190, 131.123.40[.]98 sulla porta 8041, 15.204.185[.]204, e il dominio borertors92.anondns[.]net. Questa distribuzione suggerisce una progettazione intenzionale per resistere a takedown singoli.

GBHackers ha pubblicato gli hash SHA256 dei quattro file VBScript per attività di threat hunting, con il primo stadio identificato dall'hash 08bc4e82883eb42fc5219b206555b7a02a879860c76b4a12b2f82a64f6cc9020. La disponibilità di IOC granulari permette alle organizzazioni di verificare la presenza della catena all'interno dei propri ambienti anche in assenza di rilevamento comportamentale.

"Forse la parte più interessante della catena di attacco è che utilizza client ScreenConnect modificati per propagare la catena VBScript agli endpoint ScreenConnect connessi, creando una diffusione worm-like sui sistemi appena connessi" — ricercatori Huntress, via HelpNetSecurity

Cosa fare adesso

ConnectWise ha reso disponibile una mitigazione immediata che non richiede aggiornamento di versione. Gli amministratori devono navigare in Administration > Security > Roles, individuare i ruoli technician e deselezionare esplicitamente le autorizzazioni TransferFiles e TransferFilesInSession. La modifica va applicata manualmente a ciascun ruolo: in ambienti con molti profili technician questa operazione genera una finestra di esposizione proporzionale alla completezza dell'intervento.

Huntress consiglia di analizzare retroattivamente gli audit log di ScreenConnect alla ricerca di eventi RunFiles o RanFiles con Process: Guest, pattern associato all'esecuzione automatica dei file trasferiti dai client rogue. La raccomandazione di reimaging da media known-good indica che la pulizia selettiva potrebbe non essere sufficiente a garantire la rimozione completa della catena, data la molteplicità dei meccanismi di persistenza documentati.

Perché questo pattern cambia il rischio degli RMM

La campagna del settembre 2026 rappresenta un'evoluzione qualitativa rispetto agli abusi documentati di strumenti di remote management. Fino a oggi ScreenConnect e analoghi sono stati prevalentemente sfruttati come vettore di accesso iniziale: compromettere un endpoint, stabilire persistenza, muoversi lateralmente con tecniche standard. Qui il tool stesso diventa il meccanismo di lateral movement, trasformando ogni sessione di supporto legittima in potenziale vettore di infezione automatica.

La differenza è sostanziale per chi gestisce ambienti MSP. Non si tratta più di proteggere il punto di ingresso, ma di ricalibrare la fiducia implicita che si concede al canale di connessione stesso. Il file transfer, funzione progettata per ridurre i tempi di risolzione, è stato subvertito in pipeline di propagazione che non richiede clic aggiuntivi né consapevolezza della vittima durante la fase di diffusione.

Huntress ha esplicitamente raccomandato scrutiny aggiuntivo per le installazioni on-premise di ScreenConnect, suggerendo che queste possano presentare una superficie di attacco estesa rispetto al deployment cloud. La mancanza di un fix ufficiale al momento della pubblicazione, con CVE promesso ma non ancora assegnato, lascia le organizzazioni nella condizione di dover agire su mitigazioni manuali senza patch verificabile da distribuire automaticamente.

Domande frequenti

Quali versioni di ScreenConnect sono vulnerabili?
ConnectWise non ha esplicitato versioni specifiche nella advisory del 3 settembre. La vulnerabilità interessa sia deployment Cloud che On-Premise, senza ulteriore granularità dichiarata.

È necessario disabilitare completamente ScreenConnect?
La fonte non raccomanda la disinstallazione. La mitigazione documentata consiste nella disabilitazione selettiva delle autorizzazioni di file transfer a livello di ruolo.

Il fix ufficiale è disponibile?
No. ConnectWise ha promesso CVE identifier e fix "within the week" dal 3 settembre 2026, ma al momento delle fonti disponibili né l'identificatore né la patch erano stati rilasciati.

Fonti

• https://www.helpnetsecurity.com/2026/09/07/connectwise-screenconnect-file-transfer-flaw/
• https://www.hendryadrian.com/attackers-spread-malware-through-screenconnect-file-transfers/
• https://www.archynewsy.com/hackers-weaponize-screenconnect-to-spread-worm-like-malware/
• https://gbhackers.com/rogue-screenconnect-clients/
• https://www.microsoft.com/en-us/security/blog/2026/05/26/poisoned-search-results-gpu-mining-cryptojacking-campaign-abusing-screenconnect-microsoft-net-utilities/
• https://www.helpnetsecurity.com/2026/08/05/fake-bank-of-america-email-account-guard/
• https://www.helpnetsecurity.com/2025/05/06/social-engineering-human-behavior/
• https://helpnetsecurity.com/2026/09/07/connectwise-screenconnect-file-transfer-flaw/
• https://www.connectwise.com/company/trust/advisories

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti