Come Secure gli archivi Server Secure Server

Quando gli utenti e gli amministratori di SharePoint on-premises caricano un file, quest’ultimo viene sottoposto a scansione tramite un antivirus di terze parti o motori compatibili con AMSI (come Microsoft Defender). Se il file supera tale scansione iniziale, viene considerato sicuro. Una volta pulito, rimane pulito per sempre. È proprio questo presupposto che permette ai payload di malware e ransomware di rimanere all’interno dell’archivio senza essere rilevati, a volte per anni.

Microsoft lo afferma chiaramente: la protezione da malware di SharePoint può limitare i danni, ma non costituisce l'unico punto di difesa.

Per i settori BFSI (bancario, dei servizi finanziari e assicurativo), sanitario, pubblico e OT (tecnologia operativa) o delle infrastrutture critiche, i dati a rischio comprendono documenti di conformità, cartelle cliniche, fascicoli e documentazione tecnica. Il tutto è archiviato in un archivio che continua a crescere, anno dopo anno, senza che nulla venga riesaminato per verificare il contenuto già presente.

Quello che segue si può riassumere in tre punti: come funziona effettivamente la scansione antivirus in SharePoint, cosa non copre e come dovrebbe essere un sistema di sicurezza a più livelli ed efficace per l'archivio file di SharePoint.

I dati di Enlyft relativi all'adozione tecnologica riguardano 256.295 aziende che attualmente utilizzano Microsoft SharePoint, operanti in settori che spaziano dai servizi IT al settore bancario, sanitario, petrolifero e del gas, fino alla pubblica amministrazione. Queste aziende contano in genere da 50 a 200 dipendenti e registrano un fatturato compreso tra 1 milione e 10 milioni di dollari.

È proprio questa portata a spingere gli hacker a puntare l’attenzione sugli archivi SharePoint e a considerarli obiettivi di grande valore.

Quanto detto finora non significa che SharePoint non protegga i propri server o trascuri la sicurezza dei file. Secondo la documentazione di Microsoft, SharePoint Server con due possibili interfacce di scansione:

• VSAPI (Virus Scanning API), un'interfaccia di integrazione antivirus per SharePoint che consente ai software antivirus di terze parti compatibili di eseguire la scansione dei documenti durante operazioni quali il caricamento e il download.

• AMSI (Antimalware Scan Interface), un framework di integrazione antimalware di Microsoft che consente a SharePoint Server inviare file a motori antivirus compatibili con AMSI (come Microsoft Defender) per la scansione alla ricerca di malware durante le operazioni sui contenuti supportate.

SharePoint Server può essere configurato per utilizzare VSAPI, AMSI o la modalità automatica. Indipendentemente dall'opzione selezionata, solo un motore di scansione alla volta esegue l'analisi di un file.

La scansione è basata sugli eventi e viene attivata quando gli utenti caricano o scaricano documenti, non in modo retroattivo né periodico. Solo un motore (il Microsoft Malware Protection Engine, comunemente noto come MpEngine.dll) esegue la verifica del file.

Punto chiave: i file vengono analizzati con un unico motore, al momento del caricamento o del download, utilizzando le firme e le funzionalità di rilevamento attuali di tale motore.

Questo approccio non è concepito per individuare minacce veicolate da file appositamente progettate per eludere la logica di rilevamento di quel particolare motore. Le minacce persistenti avanzate, in particolare, spesso sfruttano proprio questo limite, rimanendo inosservate per lunghi periodi.

Tale persistenza offre agli autori degli attacchi la possibilità di sfruttare a fini malevoli i contenuti affidabili di SharePoint. Esistono già casi documentati di attacchi in cui gli autori delle minacce hanno abusato di siti SharePoint compromessi per ospitare documenti di phishing e link dannosi.

Un file zero-day supererà la scansione proprio come un file pulito, semplicemente perché non esiste ancora alcun motore in grado di segnalarlo. E poiché SharePoint non esegue una nuova scansione dei contenuti esistenti in un secondo momento, un file zero-day che supera la scansione il primo giorno non verrà sottoposto a un secondo controllo il duecentesimo giorno, nemmeno dopo che il fornitore avrà rilasciato un aggiornamento delle firme in grado di individuarlo.

Le minacce sconosciute seguono la stessa logica. In assenza di una firma associata, l’analisi statica (quella effettuata dai motori antivirus) non è in grado di rilevare la minaccia.

Nota: si tratta di lacune nell'ambito di applicazione piuttosto che di difetti. L'antivirus nativo Server SharePoint Server è stato progettato per eseguire controlli puntuali in momenti specifici, non per verificare continuamente un archivio in continua crescita e soggetto a versioni successive alla luce di un panorama delle minacce in continua evoluzione.

Nel luglio 2025, Microsoft ha reso noto lo sfruttamento attivo di una catena di vulnerabilità che consentiva l’esecuzione di codice remoto senza autenticazione e che interessava SharePoint Server on-premises: CVE-2025-49706, CVE-2025-49704, a cui si sono successivamente aggiunte CVE-2025-53770 e CVE-2025-53771. L'exploit non richiedeva credenziali né un accesso per funzionare.

Microsoft ha poi rilasciato una patch, e alla catena di exploit è stato dato un nome: ToolShell.

Secondo l’analisi di Eye Security, citata da Infosecurity Magazine, sono stati individuati 396 sistemi compromessi in 145 organizzazioni distribuite in 41 paesi. Il settore pubblico è stato quello più colpito, rappresentando il 30% delle infezioni confermate, mentre gli Stati Uniti da soli hanno rappresentato il 31% del totale. Da parte sua, la Shadowserver Foundation ha segnalato che oltre 10.700 istanze di SharePoint sono rimaste esposte, accessibili a chiunque eseguisse la stessa catena di exploit, anche dopo che la vulnerabilità, che ha compromesso centinaia di organizzazioni, è stata resa pubblica. Storm-2603, uno dei gruppi all’origine dell’exploit, ha sfruttato tale esposizione per diffondere il payload del ransomware Warlock.

Una volta entrati, Storm-2603 ha utilizzato credenziali rubate e strumenti di amministrazione legittimi per muoversi lateralmente tra i sistemi. Questo movimento non ha fatto scattare alcun allarme, poiché si basava su strumenti che avrebbero dovuto trovarsi lì. Storm-2603 ha installato web shell ed ha sottratto dati importanti. Ha mantenuto l’accesso anche dopo che la vulnerabilità era stata corretta, poiché gli aggressori avevano già rubato le chiavi necessarie per falsificare token di autenticazione validi.

ToolShell è stato realizzato sfruttando quattro vulnerabilità CVE, concatenate tra loro, con meccanismi di aggiramento delle patch integrati fin dall'inizio. Le vulnerabilità CVE-2025-53770 e -53771 esistono proprio perché era possibile aggirare le correzioni originali relative alle vulnerabilità CVE-2025-49704 e -49706.

Ciò che conta davvero è che un hacker si sia adattato più rapidamente del ciclo di patch, per ben due volte, sullo stesso bersaglio, nel giro di poche settimane.

I controlli statici, come i singoli antivirus che verificano un file una sola volta confrontandolo con le firme di un unico fornitore, non sono mai stati progettati, in primo luogo, per individuare una catena di exploit lato server. Inoltre, non sono in grado di difendersi da un aggressore che, dopo l'applicazione della patch, torna all'attacco con un metodo per aggirarla.

ToolShell dimostra il livello di sofisticazione ormai mirato specificatamente ai server SharePoint. Non c’è motivo di ritenere che questa sia stata l’ultima volta in cui si è verificato un exploit di questo tipo. I dati presenti su questi server sono protetti da una soluzione in grado di stare al passo con l’evoluzione delle minacce, oppure da una scansione che effettua un unico controllo e poi si considera conclusa?

A onor del vero, ToolShell non era un documento dannoso riuscito a eludere una scansione durante il caricamento. Ma la web shell (spinstall0.aspx e le sue varianti rinominate) che gli autori dell’attacco avevano inserito? Quella sì che era un file. Rimase sul server e il fatto che venisse segnalata dipendeva dagli stessi limiti descritti in precedenza: un solo motore di scansione, un solo controllo, in un unico momento.

È questo il meccanismo che collega questo episodio alla questione più ampia. L'applicazione della patch blocca specificamente la catena di exploit di ToolShell. Non ha alcun effetto sul file successivo, non ancora sottoposto a scansione, che si trova già in un repository.

Nulla di tutto ciò ha molta importanza per i contenuti rimasti intatti dal 2023, a meno che non vengano effettivamente sottoposti a scansione.

Questo è il livello che l'antivirus nativo di SharePoint non è in grado di coprire: il controllo periodico o continuo dei contenuti archiviati, comprese le versioni precedenti conservate nella cronologia delle versioni, anziché limitarsi al momento del caricamento o del download. La riscansione in tempo reale, programmata e su richiesta colma questa lacuna, ispezionando periodicamente i file man mano che i database vengono aggiornati.

Presi singolarmente, ciascuno di questi controlli colma una specifica lacuna già menzionata in precedenza. Nel loro insieme, costituiscono quel tipo di difesa a più livelli a cui fa riferimento la stessa documentazione di Microsoft quando afferma che l’antivirus integrato non è concepito come unico punto di difesa.

MetaDefender Storage Security può essere implementato attraverso diversi modelli: server fisici per installazioni hardware dirette, piattaforme di virtualizzazione (compatibili con VMware, Hyper-V e XenServer), IaaS (Infrastructure as a Service) dei principali fornitori di servizi cloud oppure tramite implementazioni containerizzate in cluster Kubernetes.

La presente lista di controllo si basa sulle linee guida della CISA relative all'exploit ToolShell.

1. Verificare lo stato della patch.

Per tutte le vulnerabilità CVE sfruttate sono disponibili aggiornamenti di sicurezza, ma i server su cui non sono state applicate le patch rimangono esposti a ToolShell. Applicare gli aggiornamenti di sicurezza di Microsoft per tutte Server di SharePoint Server interessate.

2. Verificare che AMSI sia configurato.

Un sistema AMSI implementato ma configurato in modo errato lascia lo stesso spazio di vulnerabilità che si avrebbe in assenza totale di AMSI. Verificare che l'integrazione AMSI sia abilitata e che su ogni server SharePoint sia installata una soluzione antivirus.

3. Ruotare le chiavi del sistema ASP.NET

Le chiavi di sistema rubate consentono agli aggressori di falsificare token di autenticazione validi anche dopo l'applicazione delle patch al server. L'applicazione delle patch da sola non invalida le chiavi già rubate. Effettuare la rotazione delle chiavi di sistema, applicare l'aggiornamento di sicurezza, quindi ripetere la rotazione delle chiavi di sistema. Riavviare IIS utilizzando iisreset.exe dopo ogni rotazione per rimuovere le voci dannose dai file applicationHost.config e web.config.

4. Verificare manualmente la presenza di segni di precedenti violazioni.

La CISA sottolinea che i payload .dll utilizzati in questa campagna possono essere impiegati per ottenere le chiavi di sistema. L'applicazione delle patch non rimuove il payload già installato sul server. È necessario ispezionare i sistemi e i file specifici alla ricerca di IOC (Indicatori di compromissione), non solo della vulnerabilità in sé.

5. Verificare se esistono versioni fuori produzione o fuori servizio.

Alcune istanze di SharePoint sono giunte al termine del ciclo di vita (EOL) e non ricevono più aggiornamenti di sicurezza, indipendentemente dall'eventuale attività di sfruttamento delle vulnerabilità. Verificate se le versioni utilizzate dalla vostra azienda sono ancora supportate. In caso contrario, adottate le misure necessarie.

6. Esaminare i registri alla ricerca di indicatori noti

La CISA ha individuato specifici modelli di richiesta e indirizzi IP collegati a questa campagna. Cerca nei log le richieste che corrispondono ai riferimenti della CISA.

7. Verificare i privilegi di amministrazione e di impaginazione.

Per limitare l'entità del danno, verificare chi dispone dei permessi di modifica e amministrativi su SharePoint e revocare gli accessi che non sono effettivamente necessari.

8. Valutare ciò che è già archiviato, non solo ciò che è attualmente visibile

Quanto sopra riguarda esclusivamente la catena di exploit stessa. Nessuna di queste misure valuta i contenuti già presenti nelle raccolte di documenti, compresi i file precedenti all’applicazione di qualsiasi di queste patch.

Verificare se i contenuti esistenti nel repository siano stati sottoposti a una nuova scansione dopo l'applicazione delle patch e degli aggiornamenti delle firme pertinenti, oppure se presentino ancora il verdetto di scansione originale, potenzialmente non più aggiornato.