ScreenConnect diventa worm-like e Telerik espone una RCE pre-auth con exploit pubblico

🛡️ Executive Summary

• Client ScreenConnect modificati trasferiscono automaticamente quattro VBScript alle nuove sessioni, distribuendo backdoor, privilege escalation, tunnel e XMRig.
• Telerik UI per ASP.NET AJAX espone una catena padding-oracle che può arrivare alla RCE pre-authentication in configurazioni specifiche non predefinite.
• ConnectWise non ha ancora corretto il problema di file transfer; Telerik è invece già patchato dalla versione 2026.2.708, ma ora esiste un exploit pubblico.

Due nuove ricerche mostrano come software amministrativo e componenti web enterprise possano diventare moltiplicatori dell’attacco anche in scenari molto differenti. Huntress ha ricostruito una campagna nella quale client ConnectWise ScreenConnect modificati trasferiscono automaticamente una catena di quattro VBScript ai nuovi sistemi collegati, producendo un comportamento simile a quello di un worm. Parallelamente è stato pubblicato un exploit completo per una catena di vulnerabilità in Telerik UI for ASP.NET AJAX che, in determinate configurazioni, consente a un attaccante non autenticato di trasformare un padding oracle AES-CBC in esecuzione remota di codice. Nel primo caso l’attività è già stata osservata su organizzazioni reali; nel secondo non risultano ancora exploit confermati in-the-wild.

ScreenConnect passa da backdoor legittima a meccanismo di propagazione

La campagna individuata da Huntress parte da vettori diversi ma converge sempre sullo stesso risultato. In un incidente la vittima viene convinta attraverso una truffa di supporto tecnico ad aprire Quick Assist; in un secondo caso esegue un installer MSI probabilmente consegnato tramite phishing; in un terzo cerca online un falso modulo di rimborso Geek Squad e scarica un client ScreenConnect controllato dagli aggressori. Questo schema prolunga direttamente la campagna RMM osservata in 46 Paesi, nella quale ScreenConnect e ConnectWise venivano utilizzati come payload intercambiabili insieme a GoTo e LogMeIn. La novità è ciò che accade dopo l’installazione: il client ScreenConnect malevolo non si limita più a fornire accesso remoto, ma avvia ripetutamente wscript.exe per eseguire quattro file denominati 1.vbs, 2.vbs, 3.vbs e 4.vbs. La ricostruzione tecnica di Huntress mostra che questi script profilano il sistema, scelgono il payload più adatto e infine possono trasformare la macchina compromessa in un nuovo punto di distribuzione.

Quattro VBScript scelgono il payload in base alle difese presenti

Il primo stage, 1.vbs, costruisce una variabile di stato a tre bit. Controlla se ScreenConnect è già installato, enumera prodotti di sicurezza come CrowdStrike, SentinelOne, Sophos, Malwarebytes, Cisco AMP e Huntress, verifica se Microsoft Defender è l’unica protezione presente e controlla anche la quantità di RAM, presumibilmente per evitare ambienti di analisi troppo ridotti. Il risultato viene scritto in %TEMP%\value.txt. Il secondo e il terzo script recuperano da Dropbox configurazioni e payload cifrati, mentre 4.vbs costruisce uno script PowerShell che decifra il contenuto tramite AES-CBC, estrae sys_cache.zip e avvia PyTorchFix.ps1. La tecnica continua una tendenza già emersa nella campagna SMOKE#SCREEN, dove ScreenConnect firmato veniva installato attraverso falsi aggiornamenti Adobe e Zoom, ma qui la logica è più adattiva: la macchina viene classificata prima di decidere quale componente installare.

Le combinazioni osservate portano a risultati differenti. Gli stati 000 e 001 installano una backdoor ScreenConnect a livello utente; 010 distribuisce strumenti per persistence e privilege escalation; 011 porta tunnel di rete e un miner XMRig. Nel ramo destinato all’escalation, il PowerShell costruisce un eseguibile Password.exe, abusa del protocol handler ms-settings: e di ComputerDefaults.exe per ottenere un UAC bypass, tenta di neutralizzare AMSI e aggiunge C:\Users alle esclusioni di Defender. La tecnica del multi-RMM non è nuova: Venomous Helper installava contemporaneamente SimpleHelp e ScreenConnect per creare accessi ridondanti. La differenza è che in questa campagna ScreenConnect non rappresenta soltanto un secondo canale di controllo, ma diventa parte del loader stesso.

Leggi anche: Faronics Deploy diventa un trampolino per installare ScreenConnect dopo il phishing

Il client modificato infetta automaticamente le nuove sessioni ScreenConnect

La parte più pericolosa emerge dall’analisi dei client modificati. Quando il sistema rileva una nuova connessione Host, legge i quattro VBScript precedentemente copiati in C:\Users\Public\Libraries\Default\Lib\Lib1, li registra nel meccanismo virtuale di trasferimento file di ScreenConnect e crea un messaggio con azione Run. Il sistema appena collegato riceve ed esegue quindi automaticamente la stessa catena. Huntress definisce il comportamento worm-like perché ogni endpoint compromesso può propagare gli script alle nuove connessioni ScreenConnect senza richiedere un nuovo phishing per ogni macchina. Dopo una disconnessione l’identificatore della sessione viene eliminato dalla lista locale, permettendo che una successiva riconnessione possa essere colpita nuovamente. Il fenomeno rende ancora più rilevante la recente diffusione di campagne che abusano di software RMM legittimo come livello di accesso persistente: la relazione di fiducia tra host e client diventa qui direttamente il meccanismo di replicazione. ConnectWise aveva già pubblicato il 3 settembre un advisory sul comportamento del file transfer di ScreenConnect, dichiarando coinvolti sia ambienti cloud sia on-premise e specificando che una correzione è ancora in sviluppo. Fino alla patch definitiva, il vendor raccomanda di disabilitare il permesso TransferFiles, oppure TransferFilesInSession nelle versioni legacy. Huntress suggerisce inoltre di cercare nei log ScreenConnect eventi RunFiles o RanFiles relativi a script eseguiti come Process: Guest. Per gli host effettivamente coinvolti la raccomandazione è più drastica: reinstallazione pulita o reimage da media noto, perché persistence, UAC bypass, Defender tampering e accessi RMM aggiuntivi rendono difficile considerare affidabile una semplice bonifica puntuale.

Telerik trasforma un padding oracle in una RCE senza autenticazione

Il secondo sviluppo riguarda Progress Telerik UI for ASP.NET AJAX, ma il quadro operativo è differente. La società di sicurezza TantoSec ha pubblicato una catena completa e un tool denominato telerik-rau-exploit che combinano diverse vulnerabilità nel componente RadAsyncUpload. Le versioni interessate vanno dalla 2010.1.309 alla 2026.2.519, mentre 2026.2.708, pubblicata l’8 luglio, chiude il percorso di attacco. La catena non è però sfruttabile in ogni installazione: deve esistere una pagina che utilizza RadAsyncUpload e il server deve essere configurato con una chiave di cifratura esplicita non predefinita. Questa precisazione è essenziale perché impedisce di trasformare la pubblicazione del PoC in un allarme indiscriminato su tutte le installazioni Telerik. L’ingresso è CVE-2026-13182. RadAsyncUpload utilizza AES-CBC per cifrare il proprio stato client-side ma, nelle configurazioni vulnerabili, il server restituisce comportamenti differenti a seconda che i dati manipolati producano un padding valido oppure un errore nella successiva interpretazione JSON. Questa differenza crea un padding oracle: inviando un numero elevato di richieste, l’attaccante può dedurre progressivamente informazioni sul plaintext cifrato senza conoscere la chiave. Il metodo pubblicato richiede circa 127.000 richieste e nell’ambiente di laboratorio ha impiegato circa un’ora, quindi non si tratta di una RCE istantanea ma di una procedura automatizzabile.

CVE-2026-13181 permette di caricare un tipo .NET arbitrario

Una volta forgiata la configurazione cifrata, entra in gioco CVE-2026-13181, vulnerabilità di type resolution. Il controllo accetta un tipo .NET indicato nella configurazione senza applicare una allowlist sufficiente e lo deserializza. TantoSec utilizza quindi un gadget capace di caricare una DLL mixed-mode controllata dall’attaccante; il codice nativo della libreria viene eseguito non appena l’assembly viene caricato, ottenendo RCE con i privilegi dell’application pool IIS. CVE-2026-13183 permette inoltre di ricostruire l’oracolo attraverso differenze temporali anche quando customErrors nasconde i messaggi dettagliati. La correzione pubblicata da Progress sostituisce la costruzione crittografica vulnerabile e il vendor indica l’upgrade come soluzione definitiva. Il contesto storico rende il disclosure particolarmente rilevante. Lo stesso RadAsyncUpload possiede una lunga storia di sfruttamento: Progress aveva già documentato l’abuso combinato delle vecchie CVE-2017-11317 e CVE-2019-18935 da parte della campagna Blue Mockingbird. Questa persistenza delle vecchie superfici applicative è coerente con quanto osservato anche su altri prodotti Progress, come LoadMaster, dove una RCE pre-authentication già sfruttata ha imposto patch e ricerca retrospettiva di compromissioni. La differenza, al 7 settembre, è che per le nuove CVE Telerik non esistono prove confermate di sfruttamento in-the-wild e nessuna delle falle risulta nel catalogo KEV di CISA.

Continua con:

• CISA alza il rischio sulle vulnerabilità già sfruttate e sulle catene RCE

Il problema comune è la fiducia concessa ai componenti amministrativi

ScreenConnect e Telerik non condividono né la vulnerabilità né il vettore, ma arrivano allo stesso risultato attraverso due forme differenti di fiducia. Nel primo caso un client RMM legittimo viene modificato per utilizzare le normali funzioni di file transfer e remote execution come sistema di propagazione. Nel secondo un componente ASP.NET fidato interpreta dati cifrati controllabili dal client e finisce per trasformare un errore crittografico in caricamento arbitrario di codice. Per i difensori le priorità sono quindi differenti. Su ScreenConnect occorre disabilitare temporaneamente il trasferimento file secondo l’advisory ConnectWise, cercare 1.vbs–4.vbs, WindowsServiceHost.vbs, PyTorchFix.ps1, installazioni ScreenConnect non autorizzate, UltraViewer e connessioni verso l’infrastruttura indicata da Huntress. Su Telerik la misura decisiva è portare UI for ASP.NET AJAX almeno alla versione 2026.2.708, senza confidare semplicemente in chiavi personalizzate più robuste: il padding oracle pubblicato non ha bisogno di conoscerle. In entrambi i casi il problema supera la singola firma malware. Quando un attaccante riesce a utilizzare le stesse funzioni che amministratori e applicazioni considerano affidabili, la detection deve concentrarsi sulla sequenza operativa e non soltanto sul nome del software eseguito.