La direzione dell'infezione è quella che rende questa storia diversa dalle altre. Di solito è il tecnico dell'assistenza a essere la parte fidata: si collega, risolve, esce. Nella campagna documentata da Huntress e confermata da un avviso di ConnectWise del 3 settembre 2026, è il client ScreenConnect compromesso sulla macchina della vittima a infettare chi si collega. Il verso della fiducia si inverte.

I fatti

Huntress ha analizzato tre incidenti non correlati fra loro, osservati nell'agosto 2026, con vettori di accesso iniziale diversi ma esito identico. In tutti e tre i casi si parte da ingegneria sociale:

  • una truffa di finto supporto tecnico che convince l'utente a eseguire Quick Assist, dopo la quale viene installato un client ScreenConnect malevolo che contatta un server di comando e controllo;
  • un installer MSI (ScreenConnect.ClientSetup.msi) recapitato verosimilmente via phishing, che distribuisce un client configurato per comunicare su una porta non standard;
  • una ricerca in rete di un modulo di rimborso Geek Squad fasullo, che porta al medesimo risultato.

Una volta installato, il client malevolo esegue ripetutamente wscript.exe per lanciare quattro VBScript, chiamati semplicemente 1.vbs, 2.vbs, 3.vbs e 4.vbs, ognuno dei quali attiva il successivo:

  • 1.vbs profila la macchina: verifica le risorse di sistema (per esempio se la RAM supera i 5 GB), controlla se ScreenConnect sia già installato, ed enumera i prodotti di sicurezza presenti — fra gli altri Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos e Symantec Endpoint Protection. Il risultato viene scritto in %TEMP%\value.txt come variabile di stato a tre bit.
  • 2.vbs attende quel file, verifica che non contenga la parola abort, quindi scarica da Dropbox un contenuto che decodifica in %TEMP%\map.txt.
  • 3.vbs usa lo stato calcolato da 1.vbs per scegliere, all'interno di map.txt, il link Dropbox del payload appropriato, e lo salva cifrato in %TEMP%\out.enc.
  • 4.vbs avvia uno script PowerShell (runner.ps1) che decifra il payload, lo scrive in %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip ed esegue un secondo script PowerShell. Lo stesso runner.ps1 termina poi tutti i processi wscript.exe e cscript.exe e cancella la directory di staging.

I payload osservati cambiano in funzione delle difese trovate: gli stati 000 e 001 portano a una backdoor ScreenConnect a livello utente; lo stato 010 a strumenti di elevazione dei privilegi tramite bypass dell'UAC e persistenza; lo stato 011 — che corrisponde a una macchina senza ScreenConnect preesistente e con Microsoft Defender come unica protezione — a utilità di tunneling, alla disattivazione della segnalazione di Defender e dell'integrità della memoria di Windows, e a un miner di criptovaluta XMRig.

Fra gli indicatori condivisi dai tre incidenti, una chiave di registro Run chiamata WindowsServiceHost che punta a un file WindowsServiceHost.vbs nella cartella AppData dell'utente. Su alcune macchine colpite sono stati trovati anche altri strumenti di controllo remoto, come UltraViewer.

Il comportamento da worm

Il passaggio più rilevante è quello che ConnectWise ha riconosciuto nel proprio avviso. I client ScreenConnect modificati propagano la catena di VBScript agli endpoint che si connettono: collegarsi a un client infetto può far sì che il sistema Host — cioè la macchina del tecnico che presta assistenza — riceva ed esegua la stessa sequenza a quattro stadi.

Il client registra ogni ConnectionID per non colpire ripetutamente la stessa sessione attiva, ma rimuove l'identificativo alla disconnessione: una riconnessione successiva riattiva l'infezione. In pratica, una singola macchina cliente compromessa diventa un distributore di malware verso tutti i tecnici che ci lavorano sopra.

ConnectWise ha confermato che il problema riguarda il comportamento del trasferimento file nelle sessioni ScreenConnect Remote Access Support e Access, e che sono interessate sia le installazioni cloud sia quelle on-premise. Al momento non esiste una patch: l'avviso del 3 settembre annunciava l'assegnazione di un identificativo CVE e il rilascio di una correzione ufficiale «entro la settimana». Nel frattempo la raccomandazione è una mitigazione di configurazione.

Cosa significa per le aziende italiane

Il modello di assistenza remota descritto qui è esattamente quello dominante nel nostro mercato. Il tecnico che chiama, il link da cliccare, il piccolo eseguibile da avviare, la sessione che si apre: è così che funziona il supporto IT per la stragrande maggioranza delle PMI, degli studi professionali e dei negozi italiani. È anche il motivo per cui la truffa del finto operatore — che in Italia si presenta di solito come tecnico dell'operatore telefonico, del fornitore del gestionale o della banca — funziona così bene: chiede alla vittima di fare qualcosa che ha già fatto decine di volte in buona fede.

Ma il rischio maggiore non è per la vittima iniziale. È per il tecnico e per lo studio o l'MSP che rappresenta. La postazione di un tecnico di assistenza è, dal punto di vista di un attaccante, un obiettivo di enorme valore: contiene le credenziali di accesso a decine di clienti, i profili VPN, la console RMM, le password salvate nel gestore aziendale. Compromettere quella macchina significa accedere a tutto il portafoglio clienti. E in questo schema l'attaccante non deve nemmeno prendere di mira l'MSP: gli basta compromettere un cliente qualsiasi e aspettare che il tecnico si colleghi.

Va segnalato che questo attacco riesce dove i controlli tradizionali non guardano. ScreenConnect è software legittimo e firmato, il trasferimento file è una funzione prevista, e l'attività si svolge dentro una sessione autorizzata. La stessa catena, come si è visto, adatta il payload alle difese rilevate: non prova a superare un EDR di fascia alta, si limita a fare meno rumore. Questo è il motivo per cui il rilevamento in questi casi arriva dal comportamento — un client di supporto che genera ripetutamente Windows Script Host è anomalo — e non dalla firma del file.

Un'ultima considerazione, poco piacevole ma necessaria. Huntress ha raccomandato che le macchine colpite vengano reinstallate da supporti attendibili, non semplicemente ripulite. Per una PMI questo significa fermo operativo, e per un MSP significa doverlo dire al cliente. Rimandare quella conversazione, in presenza di una backdoor persistente con capacità di elevazione dei privilegi, è la scelta che costa di più.

Il quadro normativo

Un MSP o uno studio di consulenza informatica che accede ai sistemi del cliente agisce quasi sempre come responsabile del trattamento ai sensi dell'articolo 28 del GDPR. Se la postazione del tecnico viene compromessa, la violazione riguarda potenzialmente i dati personali di tutti i clienti raggiungibili da quella macchina: l'obbligo di comunicazione al titolare «senza ingiustificato ritardo» previsto dall'articolo 33, paragrafo 2, scatta per ciascuno di essi, e ciascun titolare dovrà poi valutare la notifica al Garante entro 72 ore. È uno scenario in cui l'assenza di un registro aggiornato di quali clienti siano accessibili da quale postazione rende impossibile perfino stabilire chi avvisare.

Per i soggetti in perimetro NIS2, la sicurezza della catena di fornitura e il controllo degli strumenti di accesso remoto rientrano fra le misure minime del D.Lgs. 138/2024, con la scadenza del 31 ottobre 2026 per la piena operatività delle misure di base. Un incidente significativo va pre-notificato al CSIRT Italia entro 24 ore e notificato entro 72.

Cosa fare subito

Mitigazione immediata (non richiede aggiornamenti):

  • In ScreenConnect, andare in Administration > Security > Roles, modificare ogni ruolo assegnato agli utenti e, per ciascun gruppo di sessione, deselezionare il permesso TransferFiles (TransferFilesInSession nelle versioni legacy). L'operazione va ripetuta per tutti i ruoli definiti nell'istanza e non richiede un aggiornamento di versione.
  • Applicare particolare attenzione alle installazioni on-premise, come raccomandato esplicitamente dai ricercatori.

Ricerca di compromissioni:

  • Controllare i log di audit di ScreenConnect alla ricerca di voci RunFiles o RanFiles associate a un processo guest.
  • Cercare sugli endpoint la chiave di registro Run denominata WindowsServiceHost e il file WindowsServiceHost.vbs in AppData.
  • Cercare i file 1.vbs–4.vbs, value.txt, map.txt, out.enc e runner.ps1 nelle cartelle temporanee, e sys_cache.zip in %APPDATA%\Microsoft\Windows\Templates\Classic.
  • Verificare la presenza di client ScreenConnect non autorizzati e di altri strumenti di accesso remoto non previsti dalle policy aziendali.
  • Controllare se la segnalazione di Microsoft Defender o l'integrità della memoria di Windows siano state disattivate su qualche macchina.

Riduzione strutturale del rischio:

  • Reinstallare da supporti puliti le macchine con segni di compromissione: la rimozione del malware non è sufficiente.
  • Bloccare l'esecuzione di VBScript per gli utenti standard tramite policy di applicazione, e monitorare wscript.exe avviato da processi di supporto remoto.
  • Segmentare le postazioni dei tecnici: non devono avere accesso simultaneo a tutti i clienti, e le credenziali vanno prelevate al bisogno da un gestore centralizzato con MFA.
  • Applicare un elenco di strumenti di controllo remoto autorizzati e bloccare gli altri: l'abuso di RMM legittimi è oggi uno dei vettori di accesso iniziale più frequenti.
  • Formare gli utenti sul fatto che nessun fornitore serio chiede di eseguire Quick Assist o di installare un client di assistenza a seguito di una telefonata non richiesta.