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 solito, quella con l’accesso più privilegiato.

Un attacco ransomware a un MSP è una singola intrusione che arriva a tutti i clienti contemporaneamente. Invece di entrare in 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 Backup condivise 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 fa funzionare il servizio è lo stesso accesso che un attaccante eredita.

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

• Le credenziali amministrative Backup condivise 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 i bersagli previsti tramite un fornitore di cui quei bersagli 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 in tutto il proprio portafoglio sono ciò che rende efficiente gestire un grande parco. Rendono anche efficiente attaccarlo, perché la 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 cybersecurity come categoria distinta, invece di trattarli come aziende ordinarie. Il loro ragionamento coincide con quello di un attaccante: un MSP compromesso può interrompere molte organizzazioni contemporaneamente.

• Ai sensi di NIS2, la gestione dei servizi ICT è uno dei settori ad alta criticità dell’Allegato I, includendo 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, o 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’è dentro quelle reti. L’RMM è il bersaglio di maggior valore perché non solo descrive gli ambienti cliente, ma li raggiunge anche.

Entrare in quella piattaforma di solito avviene tramite 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 finiscono nello stesso punto. L’attaccante eleva i privilegi all’interno della piattaforma, poi distribuisce il 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 rubare 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 per ogni cliente, quindi le credenziali che un attaccante ruba per muoversi negli ambienti cliente spesso governano il piano di ripristino per tutti. Gli MSP arrivano a questo punto perché le console condivise rendono economica la gestione di oltre 50 clienti, e questo compromesso è una delle sfide Backup degli MSP nel gestire molti ambienti contemporaneamente.

Quell’account è anche la via d’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 datacenter 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 una sola console controlla entrambe, un singolo accesso rubato può raggiungerle entrambe. Gli attaccanti danno la caccia ai 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 possa 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 più privilegiato, 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. Tale 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, quel divario determina 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 è deciso soprattutto dall’architettura, non da quanto bene viene gestito l’incidente. In ogni caso, il lavoro appare uguale: molti ambienti cliente vengono ripristinati contemporaneamente, tramite 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, nel 2026 solo il 39% ha recuperato almeno il 75% dei propri dati, in calo dal 57% nel 2024. ^[2]

Interrompi i tuoi stessi strumenti prima di toccare i sistemi dei clienti

Disconnetti prima le piattaforme RMM e PSA, prima che inizi qualsiasi lavoro 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 sottoporre la piattaforma ad audit per individuare account, script e attività pianificate aggiunti dall’attaccante. I sistemi dei clienti restano isolati finché non si conferma 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, invece che 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 dentro 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 che il contratto stabilisce già

Sapere cosa è sopravvissuto ti dice cosa può funzionare, ma non cosa funziona 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à di 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 ripristino, non il tempo di ripristino per singolo client

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

Storage tiering è ciò che sposta quel numero. In un repository Backup Veeam scale-out, il tier di performance conserva i dati recenti per un ripristino rapido, mentre i tier di capacità e di archiviazione gestiscono retention più lunghe a costi inferiori.

Mantenere i backup recenti dei client su storage di backup on-premise presso il sito del cliente, nel tier di performance, 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 preallarme è 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 ripristinare i dati chiude la questione. Gli operatori ransomware spesso sottraggono 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 client coinvolti. Il consulente legale e l’assicuratore cyber dovrebbero essere inclusi nella risposta fin dal primo giorno, non quando i sistemi sono di nuovo online.

Backup Storage progettato per la flessibilità degli MSP

Gli MSP hanno bisogno di Backup Storage che sia Semplice da gestire, resiliente contro il ransomware e sufficientemente flessibile da supportare ambienti client eterogenei, presso i siti 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’applicazione delle regole risiede nel Storage stesso anziché in una policy software, quindi non può essere disabilitata tramite credenziali, modifiche di configurazione o comandi remoti, e le azioni distruttive vengono rimosse del tutto dall’interfaccia amministrativa invece di essere semplicemente vincolate da 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ò alterare o eliminare i backup.

• Ransomware distribuito tramite gli agent dell’MSP può scrivere nuovi backup, ma non può modificare 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’applicazione delle regole risiede in ciascuna 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 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 storage Storage con backup a prova di ransomware riducendo 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 client senza negoziare, eliminando la questione alla radice.

Qual è la migliore protezione dal ransomware per gli MSP?

Il set essenziale è l’autenticazione a più fattori 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 client. 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