Una nuova campagna malware chiamata SCKit sta sfruttando installazioni di ConnectWise ScreenConnect per trasformare una normale sessione di assistenza remota in un possibile punto d’ingresso verso altri sistemi. Il punto chiave, per aziende e fornitori IT, è che non si parla di una falla inedita: secondo quanto emerso il 12 novembre 2026, gli attacchi usano una vulnerabilità già corretta, ma aggiungono tecniche che permettono di colpire anche i tecnici e, di riflesso, altri clienti gestiti con la stessa infrastruttura.
Per una PMI questo conta molto, anche se non usa direttamente ScreenConnect: se il proprio fornitore di assistenza remota o MSP viene coinvolto, un singolo endpoint compromesso può diventare il primo anello di una compromissione più ampia. È un promemoria concreto del fatto che aggiornamenti, controllo delle sessioni remote e separazione degli accessi non sono dettagli tecnici, ma misure di continuità operativa.
Cosa è successo
Secondo l’analisi condivisa da Blackpoint Cyber APG e riportata da The Hacker News il 12 novembre 2026, la campagna in corso contro ConnectWise ScreenConnect non dipende da una nuova vulnerabilità sconosciuta. Il toolkit recuperato dagli analisti sfrutta invece la CVE-2026-84869, una falla critica con punteggio CVSS 9.9 già corretta dal produttore.
La vulnerabilità è descritta come un problema di gestione impropria dei privilegi e di autorizzazione mancante. In pratica, può consentire trasferimento di file ed esecuzione di codice attraverso una sessione remota attiva senza autorizzazione o conferma da parte dell’host. Il dato importante è che i test effettuati dagli analisti avrebbero confermato che un client ScreenConnect completamente aggiornato blocca l’esecuzione del payload che sfrutta questa falla.
Questo è l’aspetto rassicurante. Quello meno rassicurante è che il toolkit SCKit non si limita all’exploit iniziale: include anche funzioni pensate per abusare delle sessioni autentiche già aperte dagli operatori e usare le legittime funzioni di gestione di ScreenConnect per distribuire codice malevolo.
In altre parole: la patch è necessaria e utile, ma da sola non basta se l’attaccante riesce a inserirsi nel flusso operativo di un tecnico già autenticato.
Perché questa campagna è diversa da un “normale” attacco remoto
Molti attacchi ai software di assistenza remota puntano a ottenere accesso su una macchina e fermarsi lì. SCKit, invece, sembra progettato con un obiettivo più ambizioso: usare un endpoint gestito come esca per arrivare al tecnico che lo assiste e, da quel tecnico, estendersi ad altri sistemi amministrati.
Il motivo è semplice. I tecnici di un MSP o di un reparto IT si collegano ogni giorno a più macchine, spesso appartenenti a clienti diversi, e operano da postazioni che hanno accesso a strumenti amministrativi e a sessioni già autenticate. Se un attaccante riesce a colpire la workstation del tecnico, il valore dell’attacco cresce enormemente.
La logica è quella tipica degli attacchi alla supply chain dei servizi IT: non serve violare ogni singola azienda una per una, se si riesce a passare attraverso chi le gestisce.
Come agisce SCKit, in sintesi
Dalle informazioni pubblicate emerge una catena d’azione piuttosto chiara. Gli attaccanti verificano prima la presenza di ScreenConnect sul sistema bersaglio. Successivamente scaricano ed eseguono un file MSI controllato da loro, indicato come “sc.msi”, che distribuisce un batch dropper chiamato “sckit-run.bat”.
Il batch contatta poi il dominio indicato nelle analisi per recuperare uno script PowerShell, che a sua volta distribuisce vari componenti del toolkit. Tra questi c’è uno script usato per stabilire accesso remoto persistente installando due client ScreenConnect Access non autorizzati.
Il punto più interessante, e più pericoloso, riguarda però la componente chiamata RelayTrap. Questa funzione serve a effettuare una sorta di pivot inverso: invece di limitarsi a difendersi da un intervento di supporto, prova a trasformare il prossimo collegamento del tecnico in un’occasione di contagio verso la sua workstation.
In pratica, SCKit tenta di intercettare o manipolare le sessioni Guest di ScreenConnect, sostituendo il componente legittimo e rimandando il payload verso il tecnico che si collega. Se questo passaggio riesce, il malware cerca di recuperare dalla macchina del tecnico sessioni browser già autenticate, incluse informazioni come i cookie .ASPXAUTH, per poi sfruttare i privilegi esistenti e propagarsi ad altri endpoint raggiungibili.
Secondo i ricercatori, gli attaccanti possono quindi usare funzioni legittime della piattaforma, come “Run Command”, per distribuire comandi su altre macchine senza dover sviluppare un diverso metodo di esecuzione per ciascun sistema. Inoltre, l’uso degli agenti ScreenConnect esistenti permette di eseguire software aggiuntivo nel contesto NT AUTHORITY\SYSTEM.
Il ruolo della vulnerabilità CVE-2026-84869
È importante non confondere due piani diversi. Il primo è la vulnerabilità CVE-2026-84869. Il secondo è l’abuso delle sessioni legittime e delle funzioni di amministrazione una volta che l’attaccante ha già preso piede.
Sul primo piano, il messaggio è chiaro: se ScreenConnect è aggiornato, il vettore noto sfruttato da questo toolkit viene bloccato. È un dato rilevante, perché evita allarmismi inutili su una presunta “nuova falla” non ancora corretta.
Sul secondo piano, però, il rischio resta operativo: se una sessione autenticata viene rubata o se un tecnico viene compromesso, la piattaforma può essere usata come veicolo di movimento laterale. Non perché il software sia nuovamente vulnerabile, ma perché l’attaccante si comporta come un utente fidato.
Questo è uno dei motivi per cui gli strumenti di accesso remoto sono così delicati: concentrano poteri molto elevati in pochi account, spesso connessi a molti clienti e dispositivi.
Un contesto già noto alle autorità
La CVE-2026-84869 non arriva dal nulla. La vulnerabilità era già stata sfruttata in precedenti attacchi, nei quali attori malevoli avrebbero usato ScreenConnect per distribuire un payload VBScript in quattro fasi e installare infine il miner XMRig.
Un altro dettaglio rilevante è l’inserimento della falla nel catalogo KEV di CISA l’11 settembre 2026. Per le agenzie federali statunitensi, l’obbligo di applicare le correzioni era fissato al 14 settembre 2026. Questo elemento indica che il problema era già considerato concretamente sfruttato e prioritario.
Secondo la fonte, in risposta all’incidente più recente ConnectWise ha inoltre disabilitato in via precauzionale cinque estensioni di terze parti. Anche senza ulteriori dettagli in questa fonte, il segnale è chiaro: quando una piattaforma di gestione remota entra nel mirino, il perimetro da proteggere non è solo il software principale, ma anche tutto ciò che gli ruota attorno.
Cosa significa per la tua azienda
Per una PMI italiana la lezione non è “abbandonare l’assistenza remota”, ma governarla meglio. Ecco i punti pratici da verificare subito con il proprio fornitore IT o con il reparto interno.
Primo: chiedere conferma degli aggiornamenti. Se usate ScreenConnect direttamente, o se lo usa il vostro MSP, va verificato che le installazioni siano state corrette contro la CVE-2026-84869. È la misura più immediata e non andrebbe data per scontata.
Secondo: controllare chi può fare cosa. Gli account dei tecnici non dovrebbero avere più privilegi del necessario e, soprattutto, non dovrebbero operare con la stessa identità su tutti i clienti e tutti i sistemi. Segmentare gli accessi riduce il danno se una sessione viene compromessa.
Terzo: mettere sotto osservazione le sessioni remote. Funzioni apparentemente normali, come l’esecuzione di comandi o l’installazione di software da remoto, vanno registrate e rese verificabili. Se un attaccante usa strumenti legittimi, la differenza la fanno i log e la capacità di rilevare attività anomale.
Quarto: proteggere le workstation dei tecnici come asset critici. Se siete un MSP o avete un team IT interno, il computer del tecnico non è una semplice postazione d’ufficio: è una chiave di accesso a molti sistemi. Va quindi trattato con controlli rafforzati, hardening, autenticazione forte e monitoraggio continuo.
Quinto: prevedere un piano di contenimento. Se emerge un endpoint sospetto, bisogna poter isolare rapidamente la macchina, sospendere le sessioni remote attive, revocare le autenticazioni esistenti e verificare se siano stati installati client non autorizzati o meccanismi di persistenza. In questo senso, un buon presidio di sicurezza informatica fa la differenza tra un incidente locale e una propagazione a catena.
Sesto: prepararsi al peggio con copie affidabili. Se un attacco remoto si trasforma in compromissione estesa, il ripristino rapido dei sistemi diventa decisivo. Soluzioni di backup remoto ben progettate aiutano a ridurre i tempi di fermo e a recuperare operatività.
Settimo: rivedere i contratti e le procedure con il fornitore. Vale la pena chiarire chi gestisce patching, monitoraggio, logging, risposta agli incidenti e notifica in caso di compromissione. Un rapporto di assistenza efficace non si misura solo sulla velocità di intervento, ma anche sulla maturità dei controlli, tema che rientra naturalmente nei contratti di assistenza informatica.
Una lezione più ampia: fiducia operativa non significa fiducia cieca
Strumenti come ScreenConnect esistono per semplificare il lavoro e, nella maggior parte dei casi, sono indispensabili. Ma proprio perché sono potenti, vanno gestiti con la stessa attenzione che si riserva a firewall, server e identità amministrative.
Il caso SCKit mostra bene un cambio di paradigma negli attacchi: non sempre l’obiettivo è bucare direttamente la rete aziendale. Sempre più spesso conviene infiltrarsi nei flussi di lavoro, rubare sessioni già valide e sfruttare strumenti approvati dall’azienda. Quando succede, il problema non è solo tecnico: è di processo, di governance e di visibilità.
Per questo aggiornare resta fondamentale, ma non è l’unica risposta. Servono segmentazione, controllo degli accessi, registrazione delle attività e capacità di riconoscere quando un’azione formalmente lecita non è, in realtà, legittima.
Domande frequenti
Se il software è aggiornato, il rischio è eliminato?
No, il rischio legato all’exploit noto viene ridotto in modo decisivo, ma resta il problema delle sessioni autenticate rubate o abusate. Per questo patching e controllo operativo devono andare insieme.
Riguarda solo gli MSP?
No. Colpisce in modo particolare MSP e team IT che usano strumenti di accesso remoto, ma anche l’azienda cliente è esposta se il proprio fornitore viene compromesso o se un endpoint gestito diventa il punto di partenza dell’attacco.
Cosa conviene fare subito in azienda?
Verificare patch e versioni, rivedere i privilegi degli operatori, controllare i log delle sessioni remote e chiedere al fornitore come protegge le postazioni dei tecnici e come reagisce a un sospetto di compromissione.