Impresa Digitale: attacchi agli MSP via ScreenConnect, cosa verificare

Una campagna attiva sfrutta ambienti ScreenConnect compromessi per colpire i clienti degli MSP, mentre N-able corregge zero-day in N-central. Ecco cosa verificare.

Impresa Digitale: attacchi agli MSP via ScreenConnect, cosa verificare
  • Campagna attiva contro gli MSP: ambienti ScreenConnect compromessi installano client di accesso remoto non autorizzati sui dispositivi dei clienti. Huntress conta 6 MSP compromessi e oltre 286 endpoint in 47 organizzazioni.
  • ConnectWise ha disabilitato in via precauzionale cinque estensioni di terze parti in circa 400 ambienti partner. Chi usa ScreenConnect on-premises deve disattivarle manualmente.
  • N-able ha rilasciato N-central 2026.4 HF2 contro zero-day divulgati pubblicamente l’8 novembre: le installazioni on-premises vanno aggiornate il prima possibile.

Per molte aziende il rischio informatico non passa più soltanto dalla propria rete, ma dagli strumenti con cui i fornitori IT la gestiscono a distanza. In questi giorni due piattaforme di gestione remota usate dai managed service provider (MSP), ScreenConnect di ConnectWise e N-central di N-able, sono al centro di due incidenti distinti. La lezione è la stessa: chi controlla l’accesso remoto controlla i dispositivi dei clienti.

Cosa è successo

La campagna su ScreenConnect

Secondo BleepingComputer, ConnectWise sta indagando su una campagna malware attiva contro gli MSP. La campagna sfrutta ambienti ScreenConnect compromessi per distribuire client di accesso remoto fasulli sui dispositivi dei clienti. L’attività è stata individuata mercoledì dalla società di sicurezza Huntress, che ha segnalato 6 MSP compromessi e oltre 286 endpoint colpiti in 47 organizzazioni, con numeri ancora in crescita.

Secondo Huntress, gli attaccanti usano la funzione Run Command di ScreenConnect per installare sugli endpoint gestiti client ScreenConnect non autorizzati. Questi client garantiscono un accesso remoto esterno all’ambiente legittimo dell’MSP. Spike Brandt di Huntress, citato da BleepingComputer, spiega che sembra trattarsi di un abuso di funzionalità legittime più che dello sfruttamento di una vulnerabilità. Huntress non ha ancora stabilito come gli aggressori entrino negli ambienti degli MSP, ma la sua telemetria indica credenziali compromesse o sessioni degli operatori dirottate.

I ricercatori segnalano anche una tecnica potenzialmente più pericolosa: la compromissione della postazione del tecnico MSP quando questi avvia una sessione ScreenConnect con un dispositivo infetto. ConnectWise ha ricevuto segnalazioni in questo senso, che sono ancora in fase di conferma.

In un advisory, ConnectWise ha confermato accessi non autorizzati ad account partner di ScreenConnect e l’installazione di software di accesso remoto non autorizzato negli ambienti dei clienti. L’azienda sospetta il coinvolgimento di cinque estensioni indipendenti di terze parti, che ha disabilitato in circa 400 ambienti partner. ConnectWise precisa tre punti. Avere quelle estensioni installate non significa necessariamente essere stati compromessi. La disattivazione non rimuove software malevolo, meccanismi di persistenza o accessi già presenti. I clienti on-premises devono disattivarle manualmente e non devono reinstallarle fino a nuove indicazioni.

Huntress aggiunge che i tag sequenziali assegnati dagli attaccanti fanno pensare che altri MSP possano essere stati compromessi in precedenza. BleepingComputer ha inoltre trovato uno script malevolo, caricato su VirusTotal il 25 luglio 2026, che fa riferimento a uno degli identificativi dei client fasulli. Il legame con la campagna attuale resta però non chiarito. Huntress, sempre secondo la testata, ha osservato nel 2026 un aumento significativo degli attacchi che usano software RMM legittimo come payload iniziale.

Gli zero-day di N-central

In parallelo, come riporta BleepingComputer, N-able ha rilasciato hotfix per vulnerabilità zero-day della sua piattaforma RMM N-central. Le falle sono state divulgate pubblicamente la notte di domenica 8 novembre dal ricercatore Sean Bales, che ha pubblicato exploit dimostrativi in un repository chiamato Able2Shell. Il 9 novembre N-able ha messo offline l’ambiente Hosted N-central in America, Europa e Asia-Pacifico e ha consigliato ai clienti on-premises di spegnere temporaneamente i server.

La versione N-central 2026.4 HF2 corregge alcune delle falle, tra cui quelle che l’azienda definisce le più critiche: escalation di privilegi locale (CVE-2026-125879 e CVE-2026-91000), XSS (CVE-2026-125880), SSRF (CVE-2026-125881) ed esecuzione remota di codice tramite path traversal (CVE-2026-125882). Il ricercatore ha anche mostrato una catena di attacco senza autenticazione che può portare alla creazione di un account Default Administrator con credenziali scelte dall’attaccante.

N-able ha comunicato che tutti i server hosted sono stati aggiornati e raccomanda ai clienti on-premises di aggiornare il prima possibile. L’azienda non ha segnalato sfruttamenti attivi, ma la società di threat intelligence Defused ha osservato scansioni alla ricerca di sistemi vulnerabili. Secondo Shadowserver, i server N-central esposti online sono passati da 1.338 a poco più di 148.

Chi è coinvolto

  • MSP e team IT che usano ScreenConnect, in particolare chi aveva installato una delle cinque estensioni disabilitate. Secondo ConnectWise, non ci sono motivi di ritenere coinvolti i partner che non le usano, ma tutti devono restare in allerta.
  • Chi gestisce ScreenConnect on-premises, che deve disattivare manualmente le estensioni.
  • Chi usa N-central on-premises, che deve installare la versione 2026.4 HF2.
  • Le aziende clienti di questi fornitori, sui cui dispositivi vengono installati i client fasulli.

Perché riguarda anche te

Gli strumenti RMM esistono per eseguire comandi, installare software e aprire sessioni remote su molti dispositivi alla volta. È quello che li rende utili ed è anche quello che li rende pericolosi se finiscono nelle mani sbagliate. I numeri di Huntress lo mostrano: 6 fornitori compromessi hanno esposto decine di organizzazioni clienti.

Per una PMI, uno studio professionale o un ente pubblico che affida la gestione IT a un fornitore esterno, il punto è concreto. La sicurezza dei propri PC dipende anche da come l’MSP protegge le credenziali dei tecnici, quali estensioni installa e se la sua console è esposta su Internet. Nella lettura Nexim, chi rientra negli obblighi NIS2 sulla sicurezza della catena di fornitura ha qui un caso pratico su cui verificare se i controlli sui fornitori esistono davvero o solo sulla carta.

Cosa fare in azienda

Subito

  1. Chiedere al proprio MSP quali strumenti di accesso remoto usa, in quale modalità (cloud o on-premises) e se aveva installato una delle estensioni ScreenConnect disabilitate.
  2. Far verificare i log, come raccomanda ConnectWise: autenticazioni, installazioni di estensioni, attività amministrative, cronologia Run Command e registri Toolbox. Secondo Huntress, la cronologia Run Command va controllata anche in assenza di allarmi.
  3. Cercare gli indicatori di compromissione diffusi da Huntress: i client ID 2588ef5c15954b10 ed ed630cc2c873b091, i file Panel-Lateral.ps1, runnew.cmd, ToolboxRelayUploader.exe e Run-Lateral-Full.bat, il dominio sc.payproofkit[.]com.
  4. Non aprire sessioni interattive con dispositivi sospetti: per le analisi vanno usati strumenti di sicurezza separati.
  5. Aggiornare N-central on-premises alla 2026.4 HF2 seguendo la guida di N-able prima di ripristinare l’accesso. Poi verificare che non esistano account amministrativi sconosciuti.

Entro 3 mesi

  1. Fare un inventario degli agenti di accesso remoto presenti sugli endpoint e rimuovere quelli non autorizzati.
  2. Pretendere, come buona pratica, autenticazione a più fattori e account nominativi per ogni tecnico che accede ai vostri sistemi.
  3. Inserire nei contratti con l’MSP obblighi di notifica tempestiva degli incidenti, accesso ai log e l’elenco di plugin ed estensioni in uso.
  4. Limitare le funzioni di esecuzione remota di script a ruoli specifici e tracciati.

Da pianificare

  1. Rendere le console RMM non raggiungibili direttamente da Internet, con accesso tramite VPN o liste di indirizzi autorizzati.
  2. Prevedere un monitoraggio di sicurezza indipendente da quello gestito dallo stesso MSP.
  3. Inserire nel piano di risposta agli incidenti la revoca rapida degli accessi del fornitore e testarla periodicamente.

Il punto di vista Nexim

Da operatore di rete, leggiamo questi episodi come la conferma che l’accesso remoto è un’infrastruttura critica e va progettato come tale: pochi punti di ingresso, canali controllati e visibilità sul traffico verso destinazioni insolite. Il calo dei server N-central esposti rilevato da Shadowserver indica quanto si possa ridurre la superficie d’attacco in poche ore, quando c’è la volontà di farlo. Le difese di rete, dal filtraggio del traffico alla sicurezza di rete e protezione DDoS, non sostituiscono il controllo sui fornitori, ma aiutano a contenere i danni. Il nostro consiglio è trattare il rapporto con l’MSP come una relazione di sicurezza, con regole, log e verifiche condivise.

Fonti

#Nexim #NeximGlobal #Cybersecurity #SicurezzaInformatica #MSP #ScreenConnect #NCentral #RMM #SupplyChainSecurity #ZeroDay #NIS2

Il video in 55 secondi