Nell’estate 2025 la catena di exploit ToolShell ha dato a chi attaccava il controllo completo dei server SharePoint on-premise, chiavi crittografiche comprese. L’episodio dice qualcosa che vale oltre quel singolo software: un ambiente di collaborazione documentale governa chi accede ai file e lascia il loro contenuto in chiaro. La resilienza che NIS2, DORA e GDPR pretendono si regge sul dato, quando la protezione resta legata al documento anche fuori dall’infrastruttura.
Indice degli argomenti
Protezione dei dati SharePoint: in poche parole
- A luglio 2025 le vulnerabilità ToolShell (CVE-2025-53770 e CVE-2025-53771) hanno permesso l’esecuzione di codice senza credenziali sui server SharePoint on-premise. Le ricerche parlano di centinaia di organizzazioni colpite in più continenti, oltre 400 secondo alcune stime, tra amministrazioni pubbliche, sanità e finanza (Microsoft, Eye Security, Palo Alto Unit 42, 2025).
- Gli attaccanti hanno aggirato autenticazione a più fattori e single sign-on e hanno sottratto le chiavi crittografiche dei server, conservando l’accesso anche dopo l’installazione delle patch.
- Il limite non riguarda un prodotto: i sistemi di gestione documentale controllano i permessi di accesso e non cifrano il contenuto dei file, che resta leggibile quando il documento esce dal loro perimetro o quando il server viene compromesso.
- Una protezione applicata al dato (cifratura all’origine che segue il file su ogni formato, con la custodia separata dall’amministrazione dell’infrastruttura) è la direzione coerente con gli obblighi di sicurezza della supply chain previsti da NIS2, DORA e GDPR.
ToolShell e i dati esposti sui server SharePoint
Il 18 luglio 2025 i ricercatori di sicurezza hanno osservato lo sfruttamento attivo di una vulnerabilità critica nei server Microsoft SharePoint installati on-premise. La falla, catalogata come CVE-2025-53770 con punteggio CVSS 9.8, permette l’esecuzione di codice da remoto attraverso la deserializzazione di dati non attendibili. Combinata con CVE-2025-53771, che aggira l’autenticazione, forma la catena battezzata ToolShell: chi attacca invia una richiesta costruita ad hoc e ottiene il controllo del server senza possedere alcuna credenziale.
Microsoft ha rilasciato patch di emergenza tra il 19 e il 20 luglio, dopo che gli aggiornamenti del Patch Tuesday di quello stesso mese si erano rivelati insufficienti. Nel frattempo il fenomeno si era già propagato. Le società di sicurezza che hanno tracciato la campagna hanno contato centinaia di organizzazioni compromesse in più continenti, con stime che in alcune analisi hanno superato le 400 vittime, distribuite tra amministrazioni pubbliche, università, strutture sanitarie e società finanziarie. Microsoft ha attribuito parte degli attacchi a gruppi collegati allo Stato cinese, con finalità di spionaggio e sottrazione di dati.
Perché patch e permessi non proteggono il contenuto dei file
Il dettaglio che rende questa vicenda istruttiva riguarda cosa gli attaccanti hanno portato via. Oltre a installare web shell, hanno estratto le chiavi crittografiche di macchina dei server, i valori che SharePoint usa per firmare e validare i dati di sessione. Con quelle chiavi in mano, chi attacca può forgiare token validi e rientrare nel sistema anche dopo che le web shell iniziali sono state rimosse e le patch applicate. Installare l’aggiornamento chiude la porta d’ingresso originale e non revoca le chiavi già sottratte: chi era entrato poteva restare.
Questo colloca l’episodio dentro una tendenza più ampia. Nel Data Breach Investigations Report 2026 Verizon indica lo sfruttamento delle vulnerabilità come primo vettore di accesso iniziale, salito al 31% dei casi analizzati. Lo stesso report osserva che nel 2025 solo il 26% delle vulnerabilità critiche presenti nel catalogo delle falle sfruttate della CISA è stato completamente rimediato, in calo rispetto al 38% dell’anno precedente, con un tempo mediano di risoluzione salito a 43 giorni.
Il ritmo con cui le organizzazioni chiudono le falle resta strutturalmente più lento di quello con cui vengono sfruttate. In quella finestra, per i file conservati sul server esposto vale un’assunzione prudente: se l’attaccante ha avuto accesso, il contenuto va considerato letto.
Permessi di accesso e contenuto in chiaro
Qui si arriva al punto che vale oltre SharePoint. Un sistema di gestione documentale fa un lavoro preciso e lo fa bene: decide chi può entrare, chi legge, chi modifica, chi scarica. È governo dell’accesso. La confusione nasce quando si dà per scontato che governare l’accesso equivalga a proteggere il file.
Sono due cose diverse. Nel momento in cui un documento lascia l’ambiente che ne controlla i permessi, sotto forma di download, sincronizzazione su un dispositivo personale, allegato di posta o copia su una chiave USB, il suo contenuto è in chiaro. Non perché qualcosa abbia fallito: è il comportamento previsto. La piattaforma ha verificato che quell’utente avesse il diritto di scaricare, e da lì la sua competenza finisce. Lo stesso accade quando è il server a cadere: chi lo controlla accede a tutto ciò che vi è archiviato, nella forma in cui è archiviato.
I numeri raccontano quanto sia comune questo scenario. La componente umana è presente nel 62% delle violazioni analizzate da Verizon (DBIR 2026), e le violazioni che coinvolgono terze parti sono cresciute del 60% in un anno, arrivando al 48% del totale.
In gran parte di questi casi l’accesso era legittimo: un dipendente che porta i file a casa, un fornitore che sincronizza una cartella di progetto, un collaboratore che ha chiuso il contratto mesi fa con i documenti già sul proprio portatile. Nessuna di queste operazioni è un’anomalia per il sistema dei permessi. Sono esattamente ciò che è autorizzato a consentire.
I limiti della cifratura nativa per i dati in SharePoint
Le piattaforme di collaborazione offrono una risposta parziale a questa lacuna, e capire dove quella risposta si ferma è più utile che sapere dove arriva. La cifratura inclusa nelle suite Office, per esempio Microsoft Purview nei piani E5, protegge bene i formati nativi Office. Sugli altri formati il comportamento cambia: alcuni restano senza protezione, altri vengono trasformati e richiedono un visualizzatore proprietario per essere aperti, con l’effetto pratico che un’immagine o un file di progetto non si apre più con l’applicazione che il team usa ogni giorno.
Restano due nodi meno visibili. Il primo è il modello di fiducia: un amministratore del tenant con privilegi elevati può aprire i file protetti. In un’organizzazione che affida la gestione dell’infrastruttura a un fornitore esterno, o che vuole separare la custodia del dato dall’amministrazione dei sistemi, questa non è una postura accettabile. Il secondo riguarda la condivisione verso l’esterno, che spesso richiede di creare un’identità dell’ospite nel proprio dominio, un passaggio che rallenta il lavoro o viene aggirato. La cifratura nativa dell’ambiente resta utile, e la sua efficacia si esaurisce dove finisce l’ambiente stesso.
Proteggere i dati SharePoint con la cifratura all’origine
La direzione alternativa sposta la protezione dal contenitore al contenuto. Il principio è cifrare il documento quando nasce, o quando entra nell’archivio, e fare in modo che la cifratura resti attaccata al file ovunque questo si sposti. Se il documento viene sincronizzato su un portatile non autorizzato, si copia e non si apre. Se finisce in un servizio cloud non governato, resta illeggibile. Se il server che lo ospita viene compromesso, l’attaccante porta via byte cifrati.
Un’architettura di questo tipo, per essere sostenibile, deve soddisfare alcune condizioni concrete: valere su qualsiasi formato senza trasformarlo, così che i file continuino ad aprirsi con gli strumenti nativi; tenere la custodia delle chiavi separata dall’amministrazione dell’infrastruttura, così che gestire il tenant non significhi poter leggere i documenti; mantenere legati al file i controlli che contano, dalla revoca dell’accesso dopo la condivisione al blocco della cattura dello schermo; integrarsi con gli ambienti già in uso senza imporre migrazioni o cambiare il modo in cui le persone lavorano.
Quest’ultimo punto decide l’adozione reale: una protezione che pretende comportamenti perfetti dagli utenti viene aggirata.
Supply chain e protezione dei dati nelle norme europee
Questo spostamento non è solo tecnico. Gli obblighi europei degli ultimi anni chiedono un controllo dimostrabile sul dato affidato a terzi, e quel controllo regge solo se viaggia con il documento. La Direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il D.Lgs. 138/2024, include tra le misure di gestione del rischio la sicurezza della catena di fornitura e attribuisce agli organi di amministrazione una responsabilità diretta sull’adozione delle misure (artt. 20 e 21).
Il Regolamento (UE) 2022/2554 (DORA), applicabile dal gennaio 2025 al settore finanziario, dedica un blocco specifico alla gestione del rischio derivante dai fornitori ICT terzi. Il GDPR, all’art. 32, chiede misure adeguate di sicurezza del trattamento, e all’art. 28 vincola il rapporto con il responsabile esterno.
Il filo comune è che il dato esce dall’azienda per definizione: verso uno studio legale, un fornitore, un partner, una società di revisione. Ogni volta che lo fa, una protezione ancorata al perimetro si ferma al confine. Le violazioni che coinvolgono terze parti, cresciute del 60% in un anno secondo Verizon (DBIR 2026), sono la misura di quanto quel confine sia poroso.
La protezione dei documenti nell’orizzonte post-quantum
C’è una ragione ulteriore per cui la scelta di cifrare oggi il contenuto pesa domani. I file sottratti in forma cifrata possono essere conservati in attesa che un computer quantistico sufficientemente potente ne renda possibile la decifrazione. È la logica nota come harvest now, decrypt later: si raccoglie adesso e si aspetta.
Per i documenti con valore a lungo termine, contratti pluriennali, proprietà intellettuale, dossier clinici, l’orizzonte della minaccia è già oggi rilevante nella scelta dell’algoritmo. Lo standard di riferimento è CRYSTALS-Kyber, formalizzato dal NIST con la pubblicazione di FIPS 203 (ML-KEM) nell’agosto 2024. Applicato al contenuto, protegge il dato anche nell’ipotesi in cui venga esfiltrato: quello che viene raccolto è cifrato, e resta tale.
Da ToolShell alla resilienza costruita sul dato
Per anni chi progetta difese si è concentrato su come impedire agli attaccanti di entrare. ToolShell ricorda che entrano lo stesso, e che l’esito di un incidente dipende soprattutto da cosa trovano una volta dentro. Finché la sicurezza resta una proprietà del server e della rete, ogni nuova falla riproporrà la stessa scena: un perimetro superato e un archivio di documenti leggibili.
Quando invece la protezione appartiene al dato, un server compromesso resta un problema di continuità operativa, e il contenuto dei documenti rimane cifrato. È su questo spostamento, più che sulla velocità con cui si applicano le patch, che si misureranno i piani di resilienza dei prossimi anni.
Partecipa alla community