Per due mesi e tre giorni, qualcuno ha letto in tempo reale tutta la posta elettronica in arrivo su Belnet, la rete nazionale belga per la ricerca e l’istruzione che collega università, centri di ricerca e amministrazioni pubbliche. L’accesso è passato per una vulnerabilità zero-day in un prodotto di terze parti che Belnet, a incidente concluso, si è rifiutata di nominare. È un caso che dice più cose su cosa NON viene comunicato nella cybersecurity europea che su cosa viene comunicato e per un lettore esperto, il silenzio è spesso il dato più interessante.

Cosa è successo

Belnet è l’infrastruttura di rete gestita dallo Stato belga che fornisce connettività a università, istituti di ricerca, ospedali universitari e diverse amministrazioni pubbliche del paese: un ruolo per certi versi assimilabile a quello del GARR in Italia o di JANET nel Regno Unito. Secondo quanto ricostruito, un attore non identificato ha sfruttato una falla zero-day in una tecnologia fornita da un vendor esterno per intercettare e copiare, senza essere rilevato, tutta la corrispondenza in ingresso destinata a Belnet e ad almeno un’organizzazione cliente, allegati compresi.

La finestra di esposizione confermata va dal 22 luglio al 25 settembre 2026, quando la falla è stata infine chiusa (alle 08:10 ora locale). Belnet stessa ha precisato che questo intervallo rappresenta soltanto il “periodo confermato di perdita dati”, non necessariamente il momento dell’accesso iniziale: in altre parole, la presenza dell’attaccante nell’infrastruttura potrebbe risalire a prima del 22 luglio, e l’organizzazione non è in grado di escluderlo. L’intrusione è stata rilevata il 24 settembre, un giorno prima della patch, una finestra di reazione rapida una volta scoperta l’anomalia, ma che segue oltre nove settimane di raccolta email passata sotto silenzio.

Il non-detto è il punto

Belnet ha confermato l’incidente e dichiarato di aver informato le autorità competenti, il Centro per la Cibersicurezza del Belgio (CCB) sta seguendo le indagini, e allertato i clienti sulle possibili conseguenze. Ma su tre punti cruciali per qualunque analisi di rischio, il comunicato resta muto: quale sia il vendor coinvolto, quale sia il prodotto specifico, e quale sia stato il meccanismo di exploitation. Senza queste informazioni è impossibile correlare l’incidente con un CVE pubblico, verificare se altre organizzazioni che usano lo stesso prodotto siano a rischio, o stimare se la vulnerabilità sia stata sfruttata anche altrove prima della disclosure.

Questo tipo di reticenza, comune quando un fornitore critico non vuole essere identificato pubblicamente, o quando accordi di responsabilità contrattuale sono ancora in negoziazione, lascia un vuoto che nella prassi CTI internazionale viene sempre più spesso criticato: un IOC condiviso in ritardo, o mai condiviso, protegge il vendor ma esporre gli altri utenti dello stesso prodotto a un rischio residuo che nessuno può misurare. Belnet non ha nemmeno indicato l’attribuzione: non si sa se dietro l’attacco ci sia un gruppo con finalità di intelligence, un broker di accessi che ha poi rivenduto la backdoor, o un attore puramente cybercriminale interessato ai dati intercettati per finalità di frode o estorsione.

Perché la geografia del bersaglio conta

Il dettaglio che rende questo incidente più di una semplice violazione email è la natura di Belnet come infrastruttura critica di ricerca e governo. Il traffico che attraversa la rete non è quello di un’azienda qualunque: include comunicazioni di ministeri, università coinvolte in progetti di ricerca strategica (incluse collaborazioni internazionali e possibili programmi a duplice uso civile-militare), ospedali universitari e istituti scientifici. Il Belgio ha già una storia di infrastrutture di rete pubblica bersaglio di operazioni attribuite a servizi di intelligence stranieri, il caso Belgacom del 2013, legato a GCHQ, resta il precedente più noto, e ogni nuovo incidente su reti governative belghe viene letto a Bruxelles, sede di NATO e Commissione Europea, con un’attenzione geopolitica che va oltre il singolo data breach.

Va detto con chiarezza: al momento non esiste alcuna attribuzione ufficiale a un attore statale per questo specifico incidente, e sarebbe scorretto presentarlo come tale. Ma il profilo tecnico, uno zero-day non banale contro un fornitore di infrastruttura, silenzioso per oltre due mesi, mirato alla raccolta passiva di corrispondenza piuttosto che a un impatto distruttivo o estorsivo immediato, è coerente con un modus operandi da cyberspionaggio più che da cybercrimine finanziario, e merita di essere seguito nelle prossime settimane per capire se emergeranno collegamenti con campagne note.

Cosa possono fare i difensori

Per i team di sicurezza di università, enti di ricerca e amministrazioni che si affidano a provider di connettività nazionale o consortile (in Italia: GARR; a livello europeo: GÉANT e le NREN nazionali), questo caso è un buon promemoria che il rischio della supply chain non riguarda solo i software desktop o le librerie open source, ma anche l’infrastruttura di rete e i suoi fornitori di componenti “invisibili”, gateway di posta, sistemi di filtraggio, appliance di sicurezza perimetrale. Alcune azioni concrete:

• Richiedere ai propri provider NREN/ISP conferma scritta se utilizzano tecnologie coinvolte in incidenti pubblicamente noti, anche quando il vendor non è nominato;
• Considerare la cifratura end-to-end della corrispondenza sensibile che transita su reti di ricerca condivise, per ridurre l’impatto di un’intercettazione a monte del provider;
• Monitorare eventuali comunicazioni successive del CCB belga o di CERT-EU, che potrebbero rilasciare indicatori più specifici una volta chiusa l’indagine;
• Nei contratti con fornitori di infrastruttura critica, inserire clausole di disclosure minima garantita (vendor, CVE, timeline) in caso di incidente, per evitare di ritrovarsi nella stessa cecità informativa vissuta ora dai clienti Belnet.

Aggiorneremo l’articolo se il CCB belga o Belnet rilasceranno ulteriori dettagli su vendor coinvolto, CVE assegnato o attribuzione.