Attacchi ransomware contro gli MSP: una guida alla protezione e al ripristino

Oggi una terza parte è coinvolta nel 48% di tutte le violazioni dei dati, con un aumento del 60% in un solo anno. ^[1] Per ogni cliente nel proprio portafoglio, un managed service provider (MSP) è una terza parte e, di norma, quella con l’accesso più privilegiato.

Un attacco ransomware a un MSP è una singola intrusione che arriva a tutti i clienti contemporaneamente. Invece di violare cinquanta aziende, l’attaccante compromette quella che già detiene l’accesso privilegiato a tutte e cinquanta, poi usa quell’accesso come farebbe un tecnico.

Poiché l’83% delle organizzazioni ha subito almeno un attacco ransomware negli ultimi due anni, evitare del tutto il ransomware non è più un piano realistico. ^[2] Per un MSP, la domanda su cui vale la pena pianificare non è se un ambiente cliente verrà colpito, ma quanti verranno colpiti nello stesso momento.

Questa guida spiega perché i gruppi ransomware prendono di mira gli MSP, come gli attaccanti passano dagli strumenti di gestione di un MSP alle reti dei clienti, perché le credenziali condivise Backup possono mandare all’aria il piano di ripristino per ogni cliente e come ripristinare più ambienti contemporaneamente.

Punti chiave

• Una singola intrusione in un MSP può distribuire ransomware a tutti i clienti contemporaneamente, perché l’accesso privilegiato che rende possibile il servizio è lo stesso accesso che un attaccante eredita.

• Le piattaforme di monitoraggio e gestione remoti (RMM) sono la via d’accesso di maggior valore, perché un RMM mantiene una connessione permanente a ogni rete cliente che un attaccante eredita intatta.

• Le credenziali amministrative condivise Backup determinano l’esito di un attacco ransomware a un MSP. Backup Storage con Absolute Immutability è ciò che protegge i dati Backup quando quelle credenziali sono nelle mani di un attaccante.

Perché i gruppi ransomware prendono di mira gli MSP

I gruppi ransomware prendono di mira gli MSP non perché siano più facili da violare rispetto ai clienti che proteggono, ma perché una singola intrusione può produrre molte vittime e l’accesso necessario per raggiungerle è già predisposto.

Ci sono quattro aspetti degli MSP che li rendono obiettivi di alto valore per i malintenzionati.

• Una intrusione, molte vittime: In un attacco alla supply chain di un MSP, l’attaccante raggiunge gli obiettivi previsti tramite un fornitore di cui quegli obiettivi si fidano già. Compromettere un singolo MSP può diffondere ransomware a decine o centinaia di ambienti a valle, quindi lo sforzo per vittima scende a una frazione di quanto costerebbe un attacco diretto.

• Le chiavi arrivano con il contratto: gli MSP detengono per progettazione credenziali ad alto privilegio in ogni ambiente cliente, perché l’amministrazione remota è il servizio per cui i clienti pagano. Un attaccante che prende il controllo di quelle credenziali eredita quella portata senza doverla conquistare.

• Un unico playbook va bene per ogni cliente: Gli strumenti, le convenzioni di denominazione e le baseline Sicurezza che un MSP applica su tutto il proprio portafoglio sono ciò che rende efficiente la gestione di un grande parco. Rendono anche efficiente l’attacco, perché una ricognizione eseguita una volta tende ad applicarsi ovunque.

• I regolatori sono arrivati alla stessa conclusione: Sia l’UE sia il Regno Unito hanno inserito i managed service provider nelle leggi sulla cybersicurezza come categoria distinta, invece di trattarli come aziende ordinarie. Il loro ragionamento coincide con quello di un attaccante: un MSP compromesso può interrompere le attività di molte organizzazioni contemporaneamente.

• Ai sensi di NIS2, la gestione dei servizi ICT è uno dei settori ad alta criticità dell’Allegato I, che copre i fornitori di servizi gestiti e di servizi Sicurezza gestiti. ^[3] La classificazione segue poi la definizione UE di dimensione d’impresa, quindi gli MSP con 250 o più dipendenti, oppure con un fatturato superiore a 50 milioni di euro e un bilancio superiore a 43 milioni di euro, rientrano tra le entità essenziali. ^[4]

• Il Regno Unito si sta muovendo nella stessa direzione. Il suo Cyber Sicurezza and Resilience Bill non è ancora legge, ma quando lo diventerà creerà una categoria di managed service provider rilevanti e fisserà la segnalazione degli incidenti a 24 e 72 ore. ^[5]

Come gli attaccanti entrano in un MSP tramite il tuo RMM

Ogni MSP si basa su due piattaforme. Il software di monitoraggio e gestione remoti (RMM) offre ai tecnici una connessione permanente a ogni rete cliente. Il software di automazione dei servizi professionali (PSA) contiene i ticket, i contratti e le anagrafiche clienti che descrivono cosa c’è all’interno di quelle reti. L’RMM è l’obiettivo di maggior valore perché non solo descrive gli ambienti cliente, ma li raggiunge anche.

Entrare in quella piattaforma di solito richiede una di due vie. La prima è un server di gestione lasciato esposto a internet senza patch aggiornate, e lo sfruttamento di una vulnerabilità software è oggi il principale punto di partenza delle violazioni, al 31%. ^[1] La seconda è un account tecnico senza autenticazione a più fattori, dove una password rubata basta da sola.

Entrambe le vie portano allo stesso punto. L’attaccante eleva i privilegi all’interno della piattaforma, poi distribuisce ransomware tramite gli agenti dello stesso MSP, usando lo stesso meccanismo che i tecnici usano per distribuire patch e script. Su una dashboard di monitoraggio, quella distribuzione appare come un aggiornamento software pianificato, ed è questo che rende questi attacchi così difficili da individuare.

Gli attori DragonForce hanno fatto esattamente questo nel 2025. Probabilmente hanno concatenato tre vulnerabilità in SimpleHelp, lo strumento RMM che un MSP ospitava per i propri clienti, poi hanno usato quell’accesso per mappare le loro reti prima di distribuire ransomware e sottrarre dati. ^[6]

A quel punto, l’attaccante detiene diritti amministrativi in ogni ambiente toccato dall’RMM, incluse le console che controllano i backup.

Un singolo accesso admin rubato può cancellare tutti i backup dei clienti?

In molti MSP, un account amministratore Backup controlla i backup di ogni cliente, quindi le credenziali che un attaccante ruba per muoversi tra gli ambienti dei clienti spesso governano anche il piano di ripristino per tutti. Gli MSP finiscono in questa situazione perché le console condivise rendono economica la gestione di oltre 50 clienti e questo compromesso è una delle sfide MSP Backup della gestione simultanea di molti ambienti.

Quell’account è anche la via di accesso ai backup dei dati. Molti MSP adottano un modello ibrido, mantenendo una copia locale presso ogni sede cliente e una copia offsite nel proprio data center per rispettare la regola 3-2-1-1-0: tre copie, su due supporti diversi, una offsite, una immutabile e zero errori nella verifica del ripristino.

Quando un’unica console controlla entrambe, un singolo accesso rubato può raggiungerle tutte e due. Gli attaccanti vanno a caccia dei backup per bloccare il ripristino e forzare il pagamento del riscatto e, senza di essi, il riscatto è l’unica via d’uscita. Un pilastro del backup e ripristino dei dati è mantenere backup immutabili, cioè che, durante una finestra temporale predefinita, un Backup non può essere modificato o eliminato.

Qui però serve cautela, perché molti sistemi che dichiarano di offrire backup immutabili hanno eccezioni e scappatoie nascoste. La più comune è un’impostazione: S3 Object Lock in modalità governance consente a un utente con specifiche autorizzazioni di override di rimuovere il blocco, che è esattamente ciò che fornisce un account amministratore Backup rubato.

Una soluzione a questo è Absolute Immutability, il che significa che anche l’admin con i privilegi più elevati, o un attaccante con accesso a Backup Storage, non può modificare o eliminare i dati. Questo livello di Protezione del backup contro il ransomware può essere ottenuto solo con un sistema Backup Storage che sia Sicuro-by-Design, con Zero Access per eseguire azioni distruttive. Questo Zero Access deve anche essere verificabile tramite test di terze parti.

Tra i leader IT, il 93% afferma che Backup Storage deve proteggere i backup anche quando gli attaccanti conoscono i segreti IT di un’organizzazione, mentre solo il 16% afferma che il proprio Storage è assolutamente immutabile. ^[2] Per un MSP, questo divario decide se la copia immutabile in una configurazione 3-2-1-1-0 sopravvive a un accesso rubato, per ogni cliente contemporaneamente.

Come ripristinare più clienti dopo un attacco ransomware a un MSP

Che un attacco colpisca i backup di un solo cliente o di tutti dipende soprattutto dall’architettura, non da quanto bene viene gestito l’incidente. In ogni caso, il lavoro appare uguale: molti ambienti cliente vengono ripristinati contemporaneamente, attraverso un’unica pipeline, con ogni cliente che si aspetta di essere il primo. Ciò che cambia è quanto resta da ripristinare.

Le organizzazioni stanno anche recuperando meno di quanto facevano in passato: tra quelle colpite da ransomware, solo il 39% ha recuperato almeno il 75% dei propri dati nel 2026, in calo rispetto al 57% del 2024. ^[2]

Interrompi i tuoi strumenti prima di toccare i sistemi dei clienti

Disconnetti prima le piattaforme RMM e PSA, prima che inizi qualsiasi attività di remediation sui sistemi dei clienti. Se l’attaccante mantiene ancora l’accesso al meccanismo di distribuzione, i sistemi ripuliti al mattino possono essere cifrati di nuovo entro il pomeriggio.

Questo significa disabilitare gli strumenti di accesso remoto, terminare le sessioni attive, revocare i token API e le chiavi di integrazione e verificare la piattaforma per individuare account, script e attività pianificate aggiunti dall’attaccante. I sistemi dei clienti restano isolati finché non viene confermato che il piano di gestione è pulito.

Conferma quali backup sono sopravvissuti prima di promettere a chiunque una tempistica

Con la piattaforma contenuta, stabilisci quali backup dei clienti sono integri, quali sono stati cifrati o eliminati e fino a quanto indietro arriva l’ultimo punto di ripristino pulito per ciascuno. Un calendario di ripristino costruito su backup che nessuno ha verificato è un’ipotesi con delle date allegate.

Verifica ogni punto di ripristino rispetto alla data della compromissione iniziale, anziché alla data in cui è stato eseguito il ransomware. Gli attaccanti spesso mantengono l’accesso per giorni o settimane prima di attivare la cifratura, quindi un punto di ripristino all’interno di quella finestra può reintrodurre il punto d’appoggio.

Dove Backup Storage è assolutamente immutabile, questo passaggio stabilisce quale punto di ripristino usare. Dove non lo è, stabilisce quanto è stato perso e, per alcuni clienti, la risposta decide se il ripristino sia un’opzione oppure no.

Ripristina nell’ordine già stabilito dal contratto

Sapere cosa è sopravvissuto ti dice cosa può funzionare, ma non cosa parte per primo. Quell’ordine dovrebbe essere definito in anticipo, per iscritto, su basi dichiarate: impegni contrattuali di Recovery Time Objective (RTO), esposizione normativa e criticità per il business. Nota che il volume di telefonate dopo l’evento non è uno di questi!.

Concordarlo prima di un incidente sposta la negoziazione fuori dal peggior momento possibile e dà agli account manager qualcosa a cui fare riferimento quando trenta clienti fanno la stessa domanda contemporaneamente. Un piano di risposta al ransomware documentato è dove vive quell’ordine, insieme ai ruoli, ai percorsi di escalation e ai compiti di comunicazione verso i clienti che lo accompagnano.

Pianifica la capacità di throughput del ripristino, non il tempo di ripristino per cliente

Conoscere l’ordine non ti dice quanto tempo serve. Un ripristino che dura un’ora su un cliente dura giorni su trenta, perché quando le copie on-site vanno perse, ogni cliente ripristina contemporaneamente dal data center dell’MSP e il vincolo diventa quella pipeline condivisa, inclusi i collegamenti verso ogni sede cliente, anziché un singolo job. Il throughput di ripristino misurato sull’intero parco è il numero che decide quanto dura l’incidente, e vale la pena testarlo prima che serva.

Il tiering Storage è ciò che sposta quel numero. In un repository Backup scale-out Veeam, il tier prestazioni contiene i dati recenti per un ripristino rapido, mentre i tier capacità e archivio gestiscono retention più lunghe a costo inferiore.

Mantenere i backup recenti dei clienti su storage di backup on-premise presso la sede del cliente, nel tier prestazioni, significa che i ripristini più urgenti avvengono alla velocità della rete locale, quindi il recupero dei dati dopo un attacco ransomware non resta in coda dietro la copia offsite nel data center dell’MSP, che è progettato per la retention a lungo termine.

L’orologio della reportistica parte prima che il ripristino finisca

Gli obblighi di segnalazione non aspettano il ripristino. Iniziano quando un MSP viene a conoscenza dell’incidente, quindi, secondo NIS2, un preavviso tempestivo è dovuto entro il primo giorno e una notifica più completa entro tre giorni. ^[7] Entrambe arrivano mentre i ripristini sono ancora in corso. Il disegno di legge del Regno Unito segue lo stesso schema in due fasi. ^[5]

Neppure il ripristino dei dati chiude la questione. Gli operatori ransomware spesso esfiltrano i dati prima di cifrarli, quindi un Ripristino da ransomware pulito può coesistere con una violazione soggetta a segnalazione per l’MSP e per i clienti coinvolti. Il consulente legale e l’assicuratore cyber dovrebbero essere inclusi nella risposta fin dal primo giorno, non solo quando i sistemi tornano online.

Backup Storage progettato per la flessibilità degli MSP

Gli MSP hanno bisogno di Backup Storage che sia Semplice da gestire, resiliente al ransomware e sufficientemente flessibile da supportare ambienti cliente eterogenei, presso le sedi dei clienti e nel data center dell’MSP.

Le soluzioni tradizionali spesso richiedono hardening manuale, si basano su strumenti frammentati e costringono gli MSP in modelli di prezzo rigidi che rallentano la crescita.

Object First Ootbi rende i dati Veeam Sicuro con Absolute Immutability, garantendo che nessuno, nemmeno l’admin con i privilegi più elevati o un attaccante con accesso a Backup Storage, possa modificare o eliminare i dati Backup.

L’enforcement risiede nel Storage stesso anziché in una policy software, quindi non può essere disabilitato tramite credenziali, modifiche di configurazione o comandi remoti, e le azioni distruttive vengono rimosse del tutto dall’interfaccia amministrativa anziché essere controllate tramite permessi.

Per i guasti descritti sopra, questo significa:

• Un account amministratore Backup rubato può comunque accedere ed eseguire ripristini, che è ciò che richiede il recupero, ma non può modificare o eliminare i backup.

• Ransomware distribuito tramite gli agenti dell’MSP può scrivere nuovi backup, ma non può cambiare ciò che è già stato scritto, perché l’immutabilità si applica nel momento in cui ogni Backup viene acquisito.

• Un’unica console che raggiunge entrambe le copie in una configurazione ibrida non può rimuovere il blocco su nessuna delle due, perché l’enforcement risiede in ciascun’appliance.

Gli MSP possono semplificare la gestione di più deployment con l’utilità di monitoraggio cloud Fleet Manager. Al momento dell’acquisto delle appliance, gli MSP possono scegliere tra prezzi in abbonamento basati sul consumo e in abbonamento CapEx per allinearsi al proprio modello di business.

Scarica il white paper per scoprire le sfide che gli MSP affrontano e come Object First offre un backup a prova di ransomware Storage riducendo al contempo Sovraccarico operativo.

FAQ

Bisogna pagare il riscatto?

Pagare non garantisce chiavi di decifratura funzionanti e il denaro finanzia un’operazione che attaccherà di nuovo. Un MSP con backup verificati e assolutamente immutabili può ripristinare gli ambienti dei clienti senza negoziare, eliminando la questione.

Qual è la migliore protezione dal ransomware per gli MSP?

Il set essenziale è l’autenticazione multi-fattore sulle piattaforme RMM e PSA, l’applicazione tempestiva delle patch agli strumenti di gestione esposti su Internet e credenziali e target Storage separati per ciascun cliente. Tutto ciò riduce la probabilità di una violazione, mentre Backup Storage con Immutabilità Assoluta determina se un MSP può riprendersi da una violazione.

NIS2 richiede che gli MSP siano in grado di riprendersi dal ransomware?

L’articolo 21 elenca la continuità operativa, inclusa la gestione Backup e il Disaster Recovery, tra le misure di gestione del rischio che le entità in ambito devono implementare, e la gestione dei servizi ICT è indicata nell’Allegato I come settore ad alta criticità. ^[3] La direttiva non indica una tecnologia specifica, quindi l’obbligo è dimostrare che il ripristino funzioni davvero, cosa che gli MSP possono verificare rispetto a l’elenco completo delle misure di gestione del rischio NIS2.

Riferimenti

[1] Verizon. "Vulnerability exploitation is top breach entry point, 2026 DBIR finds." 2026. https://www.verizon.com/about/news/breach-industry-wide-dbir-finds

[2] Omdia. "Recovery without Compromise: The Data-Backed Case for Backup Storage with Absolute Immutability." Research commissioned by Object First. 2026. https://objectfirst.com/recovery-without-compromise/

[3] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2)." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[4] European Commission. "Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises." 2003. https://eur-lex.europa.eu/eli/reco/2003/361/oj

[5] UK Parliament. "Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32 of 2026-27." 2026. https://bills.parliament.uk/bills/4035

[6] Sophos. "DragonForce actors target SimpleHelp vulnerabilities to attack MSP, customers." 2025. https://www.sophos.com/en-us/blog/dragonforce-actors-target-simplehelp-vulnerabilities-to-attack-msp-customers/

[7] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2), Article 23." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj