ShareFile spento a mano: notificare una violazione senza CVE, patch o IOC

La sera del 9 luglio 2026 Progress Software ha inviato a una parte dei clienti ShareFile un'istruzione che somiglia a un allarme antincendio: spegnete manualmente i server Windows che ospitano gli Storage Zone Controller. Non "applicate questo aggiornamento". Non "bloccate questo IP". Spegnete fisicamente la macchina. L'email è diventata pubblica il giorno dopo, quando un amministratore l'ha pubblicata su r/sysadmin di Reddit, e il 12 luglio la status page di ShareFile riportava i clienti con Storage Zone Controller come "non operativi". Progress ha dichiarato di stare rispondendo a una "minaccia esterna credibile" e di non avere "alcuna indicazione di accessi non autorizzati ad account o dati ShareFile". Ciò che non ha detto: quale vulnerabilità, quale attore, quali indicatori cercare, quando arriverà una patch. Al momento non esiste.

Questa combinazione — un ordine di spegnimento immediato senza CVE, senza patch e senza indicatori di compromissione — è la peggiore posizione di partenza possibile per chi adesso ha un orologio regolatorio che gira contro. Questo articolo parla proprio di quel vuoto: perché un'appliance di trasferimento file esposta è l'ultimo posto in cui vuoi restare al buio, e come si costruisce una notifica difendibile NIS2 o DORA quando il fornitore non ti ha lasciato nulla con cui notificare.

Cosa ha detto Progress (e cosa no)

Il componente colpito è circoscritto ma importante. Uno Storage Zone Controller (SZC) non è il cloud di ShareFile. È un server Windows/IIS on-premise che il cliente gestisce in proprio, così che i file regolamentati restino sul suo storage mentre il cloud ShareFile gestisce condivisione e orchestrazione. Per progetto lo SZC sta al bordo della rete, raggiungibile da internet — è così che il piano cloud dialoga con lui. I tenant solo-cloud non sono interessati; le organizzazioni in scope sono esattamente quelle che hanno scelto il self-hosting per motivi di residenza del dato o di compliance, quindi quelle che custodiscono i file più sensibili.

Secondo il report di BleepingComputer (10 luglio 2026) e la copertura di The Hacker News dello stesso giorno, Progress ha disabilitato gli account interessati "per abbondante prudenza", ha avvisato che la disattivazione lato cloud non era sufficiente — l'host andava spento — e ha promesso un aggiornamento entro 24 ore. L'invito a cercare "file .aspx sconosciuti" è stata l'unica briciola tecnica, e parla chiaro: punta dritto a una web shell.

Perché un'appliance di file transfer è il posto peggiore in cui spegnersi

Progress è l'azienda che possedeva MOVEit quando Cl0p trasformò un singolo zero-day nel più grande evento di esfiltrazione di massa del 2023, colpendo oltre 2.700 organizzazioni. E non è nemmeno la prima volta che lo Storage Zone Controller di ShareFile finisce nel mirino: CVE-2023-24489, un padding-oracle su AES-CBC (CVSS 9.1) che consentiva a un attaccante non autenticato di compromettere completamente lo SZC, fu aggiunta al catalogo KEV di CISA nell'agosto 2023 dopo sfruttamento reale.

E c'è una catena molto più recente. A febbraio 2026 watchTowr ha divulgato CVE-2026-2699 e CVE-2026-2701, una catena di RCE pre-autenticazione contro lo SZC branch 5.x:

• CVE-2026-2699 (CVSS 9.8) è un bypass di autenticazione di tipo execution-after-redirect (CWE-698) su /ConfigService/Admin.aspx: il codice chiama Response.Redirect(path, false), che emette un 302 ma non termina l'esecuzione della pagina, così la funzionalità di amministrazione gira per un chiamante che semplicemente ignora l'header di redirect.
• CVE-2026-2701 (CVSS 9.1) si concatena da lì: si ripunta la "Network Share Location" verso la webroot di IIS, poi si carica uno ZIP su /upload.aspx con unzip=true, che estrae i file mantenendone l'estensione — depositando una web shell .aspx che i normali upload (rinominati in GUID senza estensione) non permetterebbero mai.

Progress ha corretto quella catena in StorageCenter 5.12.4 il 10 marzo 2026. Ecco il punto che conta per luglio: una patch chiude la porta, non sfratta l'ospite. Ogni SZC compromesso prima di marzo e aggiornato dopo porta ancora con sé qualsiasi .aspx sia stato depositato nel frattempo — ed è esattamente per questo che Progress dice anche ai clienti già patchati di cercare web shell sconosciute. Abbiamo scritto la stessa frase su UniFi, SharePoint e Zimbra in questo trimestre. Lo schema non cambia: lo scanner legge un banner verde e patchato mentre un impianto risponde di lato.

Il problema delle 72 ore: notificare una violazione che non vedi

Ora il nodo operativo. Se sei un soggetto essenziale o importante ai sensi di NIS2, o un'entità finanziaria sotto DORA, nel momento in cui "vieni a conoscenza" di un incidente significativo parte un orologio legale — e "abbiamo spento un'appliance che custodisce dati perché ce lo ha detto il fornitore" è molto difficile da sostenere come non consapevolezza.

Regime	Prima scadenza	Cosa richiede	Report finale
DORA (entità finanziarie)	4h notifica iniziale dopo la classificazione come grave	Natura dell'incidente, servizi colpiti	Intermedio a 72h, finale a 1 mese
NIS2 (Art. 23)	24h pre-allerta	Se doloso, impatto transfrontaliero	Notifica a 72h con IOC iniziali + impatto; finale a 1 mese
GDPR (Art. 33)	72h all'autorità di controllo	Natura, categorie, conseguenze probabili	Senza ingiustificato ritardo

Rileggi la riga delle 72 ore di NIS2. La notifica a 72 ore deve includere gli indicatori di compromissione e una valutazione iniziale dell'impatto. Ma in questo incidente non c'è CVE, Progress non ha pubblicato alcun IOC, e l'unica cosa che ti è stata detta di fare — spegnere la macchina — è il modo più rapido per distruggere le prove volatili da cui avresti dovuto ricavarli. Un'entità finanziaria in scope sia DORA sia NIS2 incontra prima l'orologio delle 4 ore di DORA, con ancora meno da dire.

L'auditor, sei mesi dopo: "Mi spieghi cosa è uscito dal suo Storage Zone Controller tra il 9 e il 12 luglio." Tu: "Non possiamo. Il fornitore non ha mai emesso una CVE né IOC, e abbiamo spento il server prima di acquisirne l'immagine, come da sua istruzione." L'auditor: "Quindi la vostra notifica NIS2 a 72 ore ha affermato 'nessuna esfiltrazione' sulla base di quale prova?"

Non è un'ipotesi che vuoi improvvisare. "Nessuna indicazione di accessi non autorizzati" è la frase del fornitore sul proprio piano cloud; non è un accertamento sulla tua macchina on-premise, e un regolatore non l'accetterà come tale.

Spegnere ≠ forensics: cosa perdi davvero

Spegnere è la scelta giusta di contenimento — una macchina esposta che potrebbe eseguire una web shell non deve restare online. Ma contenimento e prova sono lavori diversi, e l'ordine di spegnimento baratta silenziosamente il secondo per il primo. Quando lo SZC si spegne perdi la memoria del processo worker di IIS, la tabella delle connessioni TCP attive, ogni archivio ancora in staging in un percorso temporaneo e l'albero dei processi che ti direbbe se una shell ha generato cmd.exe. Il disco sopravvive; la storia di ciò che stava accadendo no.

L'unico registro che uno spegnimento non può cancellare è quello che non è mai stato sull'host: l'egress di rete. Che gigabyte di file dei clienti siano usciti da quello SZC verso un ASN con cui non hai mai parlato è scritto sul cavo, non in un log che l'attaccante poteva ripulire o in un'immagine di RAM che hai appena buttato. Le organizzazioni che sull'appliance di bordo hanno solo telemetria host lo scoprono nell'ordine peggiore — capiscono, a metà notifica, che l'unico testimone di cui avevano bisogno era quello che non hanno mai installato.

Remediation

Alla data di pubblicazione non esiste patch per la minaccia di luglio, perciò questo runbook assume la postura di minaccia credibile descritta da Progress e integra la catena nota di febbraio, il meccanismo più probabile.

1. Sono interessato? In scope ci sono solo gli Storage Zone Controller self-hosted — i tenant solo-cloud no. Inventaria ogni SZC e verificane la build. Il branch 5.x sotto la 5.12.4 è vulnerabile alla catena pre-auth; la v6 non è affetta da CVE-2026-2699/2701. Verifica quali sono raggiungibili da internet.

2. Patch — versione corretta esatta. Aggiorna il branch 5.x a StorageCenter 5.12.4 (rilasciata il 10 marzo 2026) o passa a una release v6. Fallo dopo la caccia alla compromissione qui sotto — patchare per primo può sovrascrivere gli artefatti.

3. Non puoi patchare ora? Controlli compensativi. Segui l'indicazione di Progress e spegni lo SZC — ma acquisisci l'immagine del disco (e, se possibile, la memoria) prima dello spegnimento, per conservare lo stato forense. Se non puoi acquisire, esporta almeno i log IIS, la tabella delle connessioni e i file recenti. Togli lo SZC da internet pubblico; limita il percorso cloud-verso-SZC ai soli range pubblicati da Progress.

4. Caccia alla compromissione. Mappa su MITRE ATT&CK e cerca:

• File .aspx sconosciuti sotto C:\inetpub\wwwroot\ShareFile\StorageCenter\...\files\ul-*\ o nella webroot in generale — l'artefatto web shell (T1505.003, Web Shell).
• Risposte 302 da /ConfigService/Admin.aspx con corpo superiore a ~10.000 caratteri — la firma del bypass execution-after-redirect (T1190, Exploit Public-Facing Application).
• Richieste all'endpoint scritto male /ConfigService/api/StroageZoneConfig — usato per estrarre lo Zone Secret cifrato.
• POST verso /upload.aspx con unzip=true, e qualsiasi "Network Share Location" riconfigurata verso la webroot invece che verso storage esterno.
• Volume in uscita sostenuto dallo SZC verso ASN mai visti, o sessioni TLS anomale — il segnale di esfiltrazione (T1567, Exfiltration Over Web Service). È l'accertamento che ti servirà per la notifica NIS2.

5. Eradicazione + verifica. Rimuovere l'.aspx e patchare non basta. Poiché la catena estrae e decifra lo Zone Secret (la chiave di firma HMAC-SHA256), trattalo come compromesso: ruota lo Zone Secret e ogni credenziale raggiungibile dall'account di servizio dello SZC, poi ricostruisci l'host da un'immagine sana invece di ripulire sul posto. Solo dopo aver patchato a 5.12.4/v6 e ruotato i segreti dichiara la macchina pulita — e registra quella dichiarazione come prova, non come parola di un amministratore.

Dove ti lascia tutto questo — e dove entra Zero Hunt

L'incidente ShareFile di luglio non è davvero una storia di patch. È una storia di prove: un regolatore chiederà cosa è successo, e la risposta onesta per la maggior parte delle vittime è "non abbiamo gli artefatti per dirlo". Quel vuoto è il problema che il terzo pilastro di Zero Hunt esiste per chiudere.

La validazione continua, schedulata e attivata dal cambiamento, fa sì che uno SZC esposto non sia qualcosa da controllare dopo l'email del fornitore — un nuovo asset di bordo innesca una campagna completa entro l'ora, e ogni accertamento, scansione e remediation è mappato su 32 framework (NIS2 incluso il Titolo 13, DORA incluso l'RTS sul TLPT, ISO 27001, SOC 2 e altri 28) e firmato ECDSA con catena di custodia al momento della scrittura. Quando scade la notifica NIS2 a 72 ore non stai ricostruendo una storia da una macchina spenta; stai esportando dal Trust Center un registro firmato e datato che già mappa un accertamento su ogni regime che lo richiede — mappatura cross-framework che elimina il lavoro ridondante di rispondere separatamente a DORA, NIS2 e GDPR.

E il testimone che lo spegnimento distrugge è quello che il secondo pilastro di Zero Hunt conserva. Il modello di AI Traffic Analysis — un motore proprietario di deep learning con quattro teste d'inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo), in esecuzione sulla GPU dell'appliance a 2,7+ Gbit/s senza alcun callback verso il cloud — vede l'egress dello SZC mentre accade. Movimento massivo di file verso un ASN sconosciuto, un beacon su una shell .aspx, una sessione TLS a un'ora anomala da una macchina che storicamente solo riceve: sono visibili sul cavo mentre l'attività è viva, non dedotti da un disco che ti è stato detto di spegnere. Quando l'auditor chiede cosa è uscito dall'edificio, è la differenza tra "non possiamo dirlo" e una risposta firmata.

Approfondimenti: quando un admin abusivo sopravvive alla patch e il divario di prove NIS2 sulle CVE note. Vedi come validazione continua e prove firmate si incastrano sulla piattaforma.