Che cos’è ToolShell e come ha colpito SharePoint

ToolShell è una suite di exploit sviluppata da un gruppo di threat actor attivo dal 2023, specializzata nella compromissione di server Microsoft SharePoint on‑premise. Nell’estate 2025 la catena di vulnerabilità ha permesso agli aggressori di ottenere privilegi di sistema, estrarre chiavi private dei certificati TLS e persino installare backdoor persistenti. La particolarità dell’attacco è stata la capacità di mantenere l’accesso anche dopo l’applicazione delle patch rilasciate da Microsoft, sfruttando configurazioni errate e credenziali di servizio ancora valide.

Gli attacchi ToolShell si basano su tre fasi principali: enumerazione dei componenti SharePoint, escalation di privilegi tramite vulnerabilità di deserializzazione e esfiltrazione di chiavi crittografiche memorizzate in Secure Store Service. Una volta ottenute le chiavi, gli hacker possono decifrare i file archiviati in librerie documentali, anche se questi sono protetti da crittografia a livello di file system.

Perché i tradizionali controlli di permesso non bastano

Molte organizzazioni si affidano esclusivamente a permessi di accesso basati su gruppi Active Directory e a sistemi di autenticazione a più fattori. Tuttavia, questi meccanismi proteggono solo l’accesso al portale SharePoint, non il contenuto dei file una volta che il server è compromesso. Quando un attaccante ottiene il controllo del servizio, può bypassare le ACL (Access Control List) e leggere o esportare i documenti in chiaro.

Un esempio concreto è il caso di una grande azienda manifatturiera italiana, che ha subito la perdita di oltre 2 TB di disegni CAD sensibili. Nonostante le politiche di permesso fossero rigorose, gli hacker hanno estratto i file direttamente dal database di contenuti (Content Database) usando le chiavi di cifratura rubate, dimostrando che la protezione deve essere spostata dal “chi può aprire” al “cosa può essere letto”.

Le lacune nella gestione delle chiavi

    • Le chiavi TLS erano archiviate in chiaro nel Secure Store Service, accessibile da account di servizio con privilegi amministrativi.
    • La rotazione automatica delle chiavi era disabilitata per motivi di compatibilità, lasciando le stesse chiavi attive per più di 18 mesi.
    • La mancanza di un modulo di Hardware Security Module (HSM) ha impedito la protezione fisica delle chiavi.

Strategie di cifratura dei dati a livello di contenuto

Per rispondere alle esigenze di NIS2, DORA e GDPR, le organizzazioni devono adottare una cifratura a livello di contenuto (file‑level encryption). Questo approccio garantisce che i dati rimangano cifrati anche se l’infrastruttura sottostante è compromessa.

Le soluzioni più diffuse includono:

    • Microsoft Information Protection (MIP): permette di applicare etichette di classificazione che attivano la cifratura AES‑256 sui documenti Office, indipendentemente dal luogo in cui vengono salvati.
    • Azure Rights Management (RMS): fornisce protezione basata su policy che segue il documento ovunque, anche fuori da SharePoint.
    • Soluzioni di terze parti come VeraCrypt o Symantec Data Loss Prevention, che offrono cifratura end‑to‑end gestita da chiavi custodite in HSM.

È fondamentale integrare queste tecnologie con un key management service (KMS) centralizzato, così da garantire rotazione periodica, auditing e revoca immediata in caso di compromissione.

Difesa in profondità: misure operative e tecniche

Oltre alla cifratura, le organizzazioni dovrebbero adottare un modello di difesa in profondità, combinando controlli preventivi, rilevamento e risposta. Alcune best practice includono:

    • Implementare network segmentation per isolare i server SharePoint da altri sistemi critici.
    • Utilizzare endpoint detection and response (EDR) con capacità di monitorare attività di PowerShell sospette, tipiche degli exploit ToolShell.
    • Abilitare audit logging avanzato su tutti gli accessi al Secure Store Service e alle API di gestione delle chiavi.
    • Eseguire penetration test periodici focalizzati su scenari di deserializzazione e injection nei componenti SharePoint.

Un approccio basato su Zero Trust Architecture aiuta a verificare ogni richiesta, anche da utenti autenticati, riducendo la superficie di attacco.

Case study: implementazione di cifratura end‑to‑end in un gruppo bancario

Una grande banca italiana, dopo aver subito un tentativo di intrusione su SharePoint, ha adottato un progetto di cifratura end‑to‑end in 12 mesi. Le fasi chiave sono state:

    • Valutazione delle librerie documentali e identificazione dei dati sensibili (PII, dati finanziari).
    • Distribuzione di Microsoft Information Protection con etichette “Confidenziale” e “Riservato”, che attivavano la cifratura AES‑256.
    • Integrazione di un HSM certificato FIPS 140‑2 per la gestione delle chiavi di cifratura.
    • Formazione del personale su policy di gestione delle chiavi e su come verificare la presenza delle etichette di protezione.
    • Monitoraggio continuo tramite SIEM (Security Information and Event Management) con alert su tentativi di decrittazione non autorizzata.

Il risultato è stato una riduzione del 78 % degli incidenti di perdita di dati e la certificazione di conformità a NIS2 entro sei mesi dalla chiusura del progetto.

Conclusioni e raccomandazioni operative

L’attacco ToolShell ha dimostrato che la sicurezza di SharePoint non può più dipendere solo da permessi e autenticazione. La cifratura dei dati a livello di contenuto, la gestione rigorosa delle chiavi e un modello di difesa in profondità sono indispensabili per proteggere le informazioni aziendali.

Le organizzazioni dovrebbero quindi:

    • Adottare soluzioni di cifratura file‑level integrate con policy di classificazione.
    • Implementare un KMS centralizzato con supporto HSM.
    • Rivedere regolarmente le configurazioni di Secure Store Service e le credenziali di servizio.
    • Introdurre pratiche di Zero Trust e monitoraggio continuo delle attività sospette.
    • Formare il personale sulla sicurezza dei dati e sulla gestione delle chiavi.

Solo così sarà possibile garantire che, anche in caso di compromissione dell’infrastruttura, i dati rimangano illecitamente inaccessibili agli aggressori, rispettando le normative europee e preservando la reputazione aziendale.