Il falso aggiornamento Zoom installa un software IT firmato e in regola

Un finto aggiornamento di Zoom o di Adobe, la revisione di un documento aziendale, un controllo di manutenzione del sistema: sono le quattro esche di SMOKE#SCREEN, campagna attiva su più ondate documentata da Securonix Threat Research, e portano tutte allo stesso punto di arrivo. Sulla macchina della vittima viene installato in silenzio un client ScreenConnect, il software di monitoraggio e gestione remota di ConnectWise, configurato per contattare un relay in mano agli attaccanti anziché un sistema aziendale autorizzato.

Il pacchetto finale è un MSI ConnectWise autentico, firmato con una catena di certificati DigiCert valida, e supera quindi i controlli degli strumenti di sicurezza che rispettano la firma del codice. L'accesso che ne deriva è pari a quello di un trojan scritto su misura, con in più il fatto che l'attività risultante somiglia a una normale sessione di assistenza tecnica. L'operazione non è stata attribuita ad alcun gruppo noto; il vettore d'accesso iniziale è ricondotto allo spear-phishing.

L'indagine è partita da un singolo dropper VBScript finito nella telemetria dell'azienda, zoom-update.vbs, ed è arrivata a un server di staging WsgiDAV attivo su 207.174.0.143:8080 che durante le analisi esponeva a un normale browser l'elenco completo delle sue directory, quindici payload distinti. La stessa macchina ospita sulla porta 8041 il relay ScreenConnect primario: consegna i file alle vittime e mantiene il controllo sugli host già compromessi. Gli hash dei payload cambiano fra una sessione di download e l'altra, il che rende inefficace il rilevamento basato sugli hash.

La consegna ruota anche su servizi di hosting fidati. Una pagina di phishing a tema Zoom scarica il proprio payload da un link condiviso Dropbox, piattaforma quasi sempre consentita negli ambienti aziendali e perciò capace di scavalcare i filtri di reputazione dei domini; un loader .NET compilato punta invece a un Cloudflare Quick Tunnel, servizio pensato per esporre temporaneamente un server locale e raramente sorvegliato. Sullo staging server gira cloudflared.exe, segno che i tunnel effimeri sono generati direttamente dall'operatore sulla propria infrastruttura.

I parametri di configurazione incorporati nei file MSI ed EXE hanno permesso di mappare tre cluster di comando e controllo distinti, ciascuno con una propria coppia di chiavi RSA. Il secondario tiene la porta 80 come ripiego, per aggirare le regole firewall in uscita che bloccano le porte non standard, e il terziario si appoggia a un dominio costruito per passare come portale amministrativo. La compartimentazione ha una conseguenza pratica: se i difensori bruciano un relay, gli altri continuano a funzionare in modo indipendente.

Dalla VBScript prudente allo smantellamento di Defender

Il primo campione mostra l'operatore nella sua fase più cauta: lo script appiattisce il flusso di esecuzione in una macchina a stati, così che nessun blocco di codice riveli da solo l'intento complessivo, e intervalla operazioni aritmetiche inutili che cambiano la firma in byte del file fra una build e l'altra. Prima di procedere controlla l'ambiente: si interrompe se la memoria fisica totale è inferiore a 2 GB, condizione tipica delle sandbox e delle macchine virtuali leggere, e si interrompe anche se fra i processi attivi compaiono Wireshark, Process Monitor, i servizi di VirtualBox, VMware Tools, XenServer o Fiddler. Superati i controlli, un cifrario XOR con chiave di sedici byte decodifica un comando PowerShell che scarica un sorgente C# da un secondo indirizzo, lo compila interamente in memoria e ne richiama il punto di ingresso. Il namespace del codice si chiama HelloWorld, con l'obiettivo di operare un depistaggio deliberato.

Il campione successivo rinuncia a ogni cautela. Distribuito dentro un archivio compresso, il file batch disattiva anzitutto l'AMSI, l'interfaccia con cui Windows sottopone a scansione i comandi PowerShell, attraverso una tecnica che ne segnala in memoria il fallimento di inizializzazione. Poi verifica di avere privilegi amministrativi e, se non li ha, si rilancia con elevazione, mostrando una richiesta UAC che un utente può approvare senza sospetto proprio perché il file si chiama SystemCheck e sembra un'utilità di manutenzione. Seguono la disattivazione di SmartScreen via registro, con riavvio di Explorer per rendere subito effettive le modifiche, due esclusioni di Defender sull'intera cartella TEMP e sul percorso dell'MSI, e la rimozione del flusso di dati alternativo Zone.Identifier, il marcatore Mark of the Web con cui Windows segnala i file scaricati da internet. L'installer viene cancellato subito dopo l'esecuzione.

L'ultimo loader analizzato inverte di nuovo la rotta: abbandona la sequenza in nove passaggi contro Defender e attende tre minuti fra l'installazione del client e l'avvio del servizio, per allontanare nel tempo eventi che i sistemi di rilevamento leggerebbero come correlati. Un commento nel sorgente cita esplicitamente la rottura della correlazione degli eventi di Elastic. Un'altra variante aggiunge invece alle esclusioni di Defender l'intera radice del disco C: e prova a modificare la configurazione di avvio del servizio, lasciando la macchina con le protezioni indebolite anche quando il download successivo fallisce. Securonix descrive questo andamento come "una corsa agli armamenti in tempo reale fra attaccante e difensore".

Un pacchetto per macOS senza vittime accertate

Fra i quindici file dello staging server compare ZoomUpdateInstaller.pkg, un pacchetto per macOS che contatta lo stesso relay primario di diversi payload Windows: è l'elemento che lega l'operazione a bersagli fuori dal mondo Windows. La ricostruzione però si ferma qui. Non è documentato come il pacchetto venisse distribuito, non risultano infezioni Mac confermate e il rapporto non chiarisce se il .pkg fosse firmato e sottoposto a notarizzazione da Apple. Accertato è che l'infrastruttura della campagna comprendesse un payload per Mac; la consegna effettiva a utenti Mac resta senza riscontro.

Sul fronte difensivo le raccomandazioni sono di limitare l'esecuzione di file MSI non fidati, monitorare i processi che tentano di manomettere i prodotti di sicurezza, verificare l'uso legittimo degli strumenti RMM già presenti in azienda, tenere d'occhio i processi PowerShell e cmd.exe sospetti e imporre impostazioni UAC rigide che impediscano agli utenti standard di scavalcare le richieste di elevazione. Il nome ScreenConnect e una firma digitale valida non bastano a stabilire che un'installazione sia autorizzata: la destinazione del relay e il modo in cui il software è arrivato sulla macchina sono le informazioni che distinguono l'assistenza approvata dallo strumento di accesso remoto di un attaccante.