Un dipendente su otto considera accettabile vendere le credenziali


Il problema del dipendente “infedele” è vecchio quanto le aziende stesse, ma sembra che il panorama stia evolvendo più velocemente del previsto nella direzione sbagliata e che una parte dei lavoratori sembra aver normalizzato comportamenti che fino a pochi anni fa sarebbero stati considerati gravissimi. Un nuovo studio pubblicato dal servizio britannico per la prevenzione delle frodi (Cifas) mostra infatti un quadro estremamente preoccupante: il 13% dei lavoratori afferma di aver venduto credenziali aziendali o di conoscere qualcuno che lo ha fatto negli ultimi dodici mesi.

Il dato assume un peso ancora maggiore se si considera che un altro 13% degli intervistati ritiene “giustificabile” vendere accessi ai sistemi aziendali, soprattutto a ex colleghi o soggetti ritenuti “fidati”. Secondo gli analisti, questo fenomeno indica un cambiamento culturale profondo nel modo in cui parte dei dipendenti percepisce il valore delle credenziali digitali e la responsabilità legata alla gestione degli accessi.

Il problema è culturale, non solo tecnologico

L’aspetto più inquietante emerso dalla ricerca è che la tolleranza verso questi comportamenti aumenta con il livello gerarchico. Lo studio evidenzia infatti che il 32% dei manager, il 36% dei direttori e addirittura il 43% degli executive di livello C-suite ritengono accettabile la vendita delle proprie credenziali aziendali in determinate circostanze. Ancora più sorprendente il dato relativo agli imprenditori: l’81% degli imprenditori coinvolti nel sondaggio ha dichiarato che il comportamento può essere giustificato

Questi numeri suggeriscono che il problema non riguarda soltanto la consapevolezza degli utenti finali, ma coinvolge direttamente la governance e la cultura organizzativa. In molte aziende, infatti, le credenziali continuano a essere percepite come strumenti operativi personali, anziché come componenti critiche della superficie di attacco aziendale.

Secondo Cifas, dietro questi comportamenti si nascondono spesso motivazioni economiche, insoddisfazione lavorativa, convinzione di non essere scoperti oppure la percezione che il gesto sia “innocuo” o che non abbia vere conseguenze.

Credenziali legittime: la porta perfetta per gli attaccanti

Dal punto di vista della cybersecurity, la vendita di account aziendali rappresenta uno scenario estremamente pericoloso. Gli attaccanti cercano sempre più spesso di ottenere accessi legittimi invece di forzare direttamente le difese perimetrali e delle credenziali autentiche permettono di aggirare numerosi controlli di sicurezza, ridurre la probabilità di rilevamento e muoversi lateralmente nei sistemi con maggiore facilità.

L’uso di identità valide è ormai centrale nelle operazioni ransomware, negli attacchi supply chain e nelle campagne di cyber spionaggio. In molti casi, gli access broker acquistano o rivendono credenziali sottratte o cedute volontariamente per poi monetizzarle nei marketplace underground.

Secondo la ricerca, i settori più esposti a una maggiore tolleranza verso comportamenti fraudolenti includono IT e telecomunicazioni, dove gli utenti possiedono spesso privilegi elevati e accessi sensibili.

La sicurezza non può dipendere soltanto dai controlli tecnici

I risultati del report mostrano chiaramente come la sicurezza aziendale non possa più basarsi esclusivamente su firewall, MFA o sistemi di monitoraggio. Le organizzazioni devono affrontare il problema anche dal punto di vista culturale e organizzativo, lavorando su formazione, consapevolezza e governance degli accessi.

Secondo Cifas, la prevenzione passa attraverso la costruzione di una vera “fraud-aware culture”, nella quale ogni dipendente comprenda le conseguenze operative, economiche e legali legate alla condivisione o vendita delle credenziali.

In questo scenario, onestamente desolante, assumono un ruolo centrale i modelli Zero Trust, la segmentazione degli accessi, il principio del privilegio minimo e il monitoraggio continuo delle anomalie comportamentali. Tuttavia, ricordiamoci che anche le architetture più avanzate rischiano di diventare inefficaci se una parte significativa del personale considera normale monetizzare l’accesso ai sistemi aziendali.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/05/07/un-dipendente-su-otto-considera-accettabile-vendere-le-credenziali/?utm_source=rss&utm_medium=rss&utm_campaign=un-dipendente-su-otto-considera-accettabile-vendere-le-credenziali




Intelligenza artificiale e criminalità Informatica: quando lo stesso strumento difende e attacca

L’AI ridisegna i confini della digital forensics e apre interrogativi inediti per magistratura e forze dell’ordine

C’è un momento preciso in cui una tecnologia smette di essere neutrale. Non è quando viene usata per fare del male, perché quella è una storia antica quanto il fuoco. È quando diventa così pervasiva, così duttile, così integrata nella catena causa-effetto del crimine da rendere irriconoscibile la distinzione tra arma e scudo. Con l’intelligenza artificiale applicata alla cybersecurity, quel momento è adesso.

Un paper depositato su arXiv il 16 ottobre 2025, dopo essere stato presentato all’APWG-EU Tech Summit and Researchers Forum di Cagliari nel giugno dello stesso anno, mette a fuoco con rara lucidità questa doppia natura dell’AI applicata alla criminalità informatica.

I suoi autori, Silvia Lucia Sanna, Leonardo Regano, Davide Maiorca e Giorgio Giacinto, lavorano tutti all’Università di Cagliari, nell’ambito del progetto SERICS finanziato dal PNRR europeo. Il titolo, sobrio e tecnico, non tradisce l’ambizione dell’analisi: Improving Cybercrime Detection and Digital Forensics Investigations with Artificial Intelligence. Ma quello che il paper contiene è molto più di un inventario di tecniche. È una mappa concettuale di un territorio in rapida trasformazione, con implicazioni che si estendono ben oltre i laboratori universitari, fino alle aule dei tribunali.

Il doppio volto dell’AI nella criminalità informatica e nelle indagini digitali

La premessa da cui muovono i ricercatori cagliaritani è scomoda ma ineludibile: i modelli linguistici di grandi dimensioni, Gemini, Copilot e ChatGPT, che oggi assistono gli analisti forensi nell’elaborazione di enormi volumi di evidenze digitali, sono gli stessi strumenti che i criminali informatici possono impiegare per nascondere le proprie tracce, automatizzare attacchi e generare contenuti sintetici difficili da attribuire.

Non si tratta di un paradosso astratto. È la descrizione operativa di un ecosistema in cui l’AI agisce simultaneamente come lente d’ingrandimento per gli investigatori e come nebbia artificiale per chi vuole sottrarsi all’indagine. Il riferimento esplicito nel paper è a un recente rapporto Europol sul cybercrime in Europa, che conferma la persistenza e la crescente complessità del fenomeno, richiedendo strumenti di contrasto all’altezza.

Sul versante difensivo, il contributo dell’AI alla forensics digitale è già consistente e documentato. I sistemi di machine learning permettono di analizzare in tempo reale flussi di dati di rete alla ricerca di pattern anomali, di classificare malware con una granularità che gli approcci signature-based non possono raggiungere, di correlare eventi distribuiti su infrastrutture eterogenee ricostruendo catene di attacco che altrimenti rimarrebbero invisibili.

I Large Language Model, in particolare, stanno emergendo come strumenti di supporto cognitivo per gli analisti: capaci di supportare la fase di reporting, producendo bozze di documenti, definendo glossari tecnici e sintetizzando le evidenze in linguaggio comprensibile anche per i non specialisti, e di accelerare il triage su volumi di prove che nessun team umano potrebbe processare nei tempi richiesti da un’indagine.

Ma è sull’altro versante, quello offensivo e anti-forense, che il paper introduce gli elementi più perturbanti.

Il caso studio: steganografia LSB generata da tre chatbot

Il contributo più originale della ricerca riguarda un caso studio condotto direttamente dai ricercatori, che vale la pena esaminare nella sua specificità tecnica. Sanna e colleghi hanno testato Gemini, Copilot e ChatGPT su due capacità distinte: la generazione di immagini con contenuto steganografico tramite tecnica LSB (Least Significant Bit) e la produzione di codice Python funzionante per la codifica e decodifica di immagini steganografiche.

La steganografia digitale applicata sulle immagini è una delle tecniche di occultamento dati più consolidate: consiste nel modificare i bit meno significativi dei pixel di un’immagine per nascondervi informazioni, in modo percettivamente invisibile all’occhio umano. L’immagine di input usata nel test è un file PNG bianco prelevato da Wikimedia, nel quale è stato incorporato il messaggio segreto “This is a secret message APWG.” Le immagini generate e i contenuti nascosti sono stati poi verificati con zsteg, un tool Linux specializzato in analisi steganografica, e con uno script esterno disponibile su GitHub.

I risultati sono significativi: tra i tre modelli testati, Copilot si è dimostrato il più performante nell’esecuzione di entrambi i compiti. Un dato che non è un dettaglio minore: emerge da un test controllato e comparativo, con implicazioni dirette sulla valutazione del rischio nei diversi ecosistemi di AI generativa.

È fondamentale riportare una precisazione che i ricercatori stessi formulano in modo esplicito: la presenza di questi chatbot in un contesto digitale non è di per sé un indicatore di criminalità o attività malevola. La tecnica steganografica, se impiegata da un criminale informatico, diventa uno strumento anti-forense, ma la stessa tecnica ha usi legittimi nella protezione delle comunicazioni. Questa distinzione, che il paper enuncia con chiarezza, è essenziale per evitare letture fuorvianti del lavoro.

La sfida per gli investigatori: quando il codice viene scritto dall’AI

Il dato che rende la ricerca particolarmente rilevante per chi lavora nelle investigazioni non è tanto la tecnica in sé, ma la democratizzazione del suo accesso. Un soggetto privo di competenze di programmazione avanzata può chiedere a un modello linguistico di generare uno script steganografico, personalizzarlo e incorporarlo in un flusso operativo d’attacco. La barriera tecnica all’ingresso si abbassa in modo radicale. La rilevabilità del contenuto nascosto, già difficile per sua natura, non peggiora sul piano tecnico, ma si moltiplica su scala: più attori potenziali, più artefatti, più rumore di fondo per gli investigatori.

Si pone poi un problema ulteriore, che il paper apre pur senza pretendere di risolverlo: come si documenta e si attribuisce, in sede processuale, un contenuto generato tramite AI? Quando il codice che nasconde le prove è stato scritto da un chatbot su richiesta dell’indagato, la catena causale che collega soggetto e artefatto diventa più complessa da dimostrare. Non si tratta ancora di un tema affrontato esplicitamente dal sistema giudiziario italiano, ma è la traiettoria logica di ciò che questo tipo di ricerca rende oggi tecnicamente possibile.

Il paper anticipa infine una visione ancora più radicale per il futuro: gli autori prevedono che l’AI sarà usata in modo sempre più pervasivo tanto nel cybercrime quanto nella digital forensics, fino a configurare scenari di AI-vs-AI interamente autonomi, in cui sistemi di attacco e sistemi di difesa si fronteggiano senza intermediazione umana diretta.

Implicazioni operative per gli investigatori

Per chi lavora sul campo, unità di cybercrime, CERT, team SOC e magistratura specializzata, il paper suggerisce alcune linee di riflessione immediate.

La prima riguarda la formazione. Se gli LLM sono strumenti già usati sia dagli analisti sia dagli attaccanti, le competenze necessarie per valutarne l’output, comprenderne i limiti e riconoscerne i pattern, devono entrare nei programmi di aggiornamento delle forze dell’ordine in modo strutturale, non episodico.

La seconda riguarda la catena di custodia digitale. In un contesto in cui contenuti generati da AI si moltiplicano, la documentazione del processo di raccolta e analisi delle evidenze deve includere procedure specifiche per l’identificazione di artefatti potenzialmente prodotti o modificati tramite AI. Non è più sufficiente certificare che un file “esiste”: occorre certificare con quale grado di confidenza si possa classificare la sua origine.

La terza, la più delicata, riguarda il valore probatorio delle analisi AI-assistite in sede processuale. Come approfondito anche nel dibattito sulla digital forensics e il diritto, gli strumenti di rilevazione automatica sono accurati ma non infallibili, e la loro accuratezza varia in funzione del modello che ha generato il contenuto e delle eventuali tecniche di offuscamento applicate. Utilizzarli come prova diretta senza un adeguato framework di riferimento e senza perizia tecnica qualificata rischia di introdurre nel processo una forma di errore sistematico difficile da contestare.

Vale la pena segnalare, infine, un ulteriore problema di contesto: l’uso di Private AI in ambito forense sta emergendo come requisito operativo nelle indagini più sensibili, proprio perché l’invio di evidenze digitali a servizi AI in cloud introduce criticità di controllo dei dati incompatibili con la catena di custodia.

Un contributo italiano al dibattito globale

Vale la pena sottolineare la provenienza istituzionale di questo lavoro, non per campanilismo, ma per una ragione sostanziale. Il paper nasce all’interno del progetto SERICS (Security and Rights in CyberSpace), uno dei spoke del PNRR dedicati alla cybersecurity, che coinvolge decine di atenei e centri di ricerca italiani. Il fatto che Silvia Lucia Sanna conduca questa ricerca nell’ambito del Dottorato Nazionale in Intelligenza Artificiale (Sapienza Università di Roma in collaborazione con l’Università di Cagliari) segnala una continuità di investimento sistemico che va ben al di là del singolo paper.

L’Italia è uno dei paesi europei in cui il dibattito sull’uso processuale dell’AI è più vivo, sia per la tradizione di dottrina giuridica in materia di prova digitale, sia per la presenza di strutture investigative specializzate con sensibilità tecnica crescente. Un lavoro come quello di Sanna e colleghi non è solo un contributo alla letteratura accademica: è un documento che può e dovrebbe alimentare la formazione delle procure specializzate e informare le linee guida che le istituzioni competenti stanno costruendo attorno all’uso investigativo dell’intelligenza artificiale.

Conclusione: la neutralità non è un’opzione

L’intelligenza artificiale non ha alleanze. Ottimizza obiettivi. Se l’obiettivo è rilevare una comunicazione criminale nascosta in un’immagine, l’AI può farlo. Se l’obiettivo è nascondere quella comunicazione in modo da complicarne l’individuazione e l’attribuzione, l’AI può farlo con la stessa competenza e, come dimostra il caso di Copilot nel test dei ricercatori cagliaritani, con una certa efficacia.

Questa simmetria non è una ragione per limitare l’uso dell’AI nella forensics. È invece una ragione per sviluppare, con urgenza e rigore, i framework tecnici, legali e procedurali che permettano di usare questi strumenti in modo robusto, verificabile e giuridicamente sostenibile.

Il paper di Sanna, Regano, Maiorca e Giacinto non offre risposte definitive. Offre qualcosa di più prezioso: dati sperimentali concreti e le domande giuste. In un campo che cambia a questa velocità, è già un contributo straordinario.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/ai-criminalita-informatica/




Sicurezza AI: i router LLM diventano il punto debole della supply chain (caso LiteLLM)

Una ricerca sistematica di UC Santa Barbara, UC San Diego, Fuzzland e World Liberty Financial ha analizzato 428 router commerciali e gratuiti, individuando intermediari che riscrivono attivamente le tool-call degli agenti di coding ed esfiltrano credenziali. L’incidente LiteLLM del marzo 2026 conferma, su scala industriale, che la minaccia non è più teorica.

Sicurezza AI a rischio: perché i router LLM stanno diventando il nuovo punto debole negli attacchi informatici

Ogni volta che un agente LLM, un Claude Code, un Codex o un Cursor, invia una richiesta a un provider di modelli, il traffico attraversa quasi sempre uno o più intermediari applicativi. Si chiamano router, o API gateway, e aggregano decine di provider dietro un’unica interfaccia compatibile con OpenAI. Gestiscono fallback, bilanciamento di carico e ottimizzazione dei costi; un singolo cambio di base URL e una nuova chiave API bastano per instradare un’intera flotta di agenti attraverso un servizio terzo.

La scelta è così banale che, in molte organizzazioni, viene presa al livello di una configurazione di sviluppo. Il fatto che, una volta puntato quel percorso, il client non abbia alcun modo di verificare crittograficamente cosa abbia davvero prodotto il modello a monte è un dettaglio che, fino a poco tempo fa, quasi nessuno ha considerato.

Un gruppo di ricercatori guidato da Hanzhi Liu (UC Santa Barbara), con Chaofan Shou (Fuzzland), Hongbo Wen (UCSB), Yanju Chen (UC San Diego), Ryan Jingyang Fang (World Liberty Financial) e Yu Feng (UCSB), ha deciso di misurarlo. Il paper «Your Agent Is Mine» (arXiv:2604.08407v1, cs.CR, 9 aprile 2026) è il primo studio sistematico sull’ecosistema dei router LLM visti come confine di fiducia della supply chain dell’IA. Il risultato è meno rassicurante del previsto.

Un man-in-the-middle “legittimo” nella sicurezza AI

Il modello di minaccia formalizzato dagli autori parte da un’osservazione architetturale semplice: il router, per sua natura, termina la sessione TLS lato client e ne apre una nuova verso il provider. Occupa quindi una posizione di man-in-the-middle applicativo non accidentale, ma intenzionalmente configurata dall’utente. Nessun TLS downgrade, nessuna forgery di certificati: basta che il client abbia puntato l’endpoint a quel servizio. Da lì il router vede in chiaro tool definition, prompt di sistema, chiavi API, output dei tool e, soprattutto, le tool-call che l’agente sta per eseguire. Può leggerle, trattenerle, riscriverle o fabbricarle ex novo.

La chain-integrity, notano gli autori, è una proprietà del tipo weakest link: in una catena di k hop (utente -> rivenditore -> aggregatore -> OpenRouter -> provider, tanto per restare su uno scenario realistico), un singolo router malevolo in qualunque posizione è sufficiente a compromettere l’intera traiettoria. Gli hop onesti a valle non possono né rilevare né annullare la modifica, perché non hanno alcun riferimento alla risposta originale prodotta dal provider.

Attacchi hacker AI: le 4 tecniche che sfruttano i router LLM

Su questa base, il team costruisce una tassonomia di quattro classi. Le due primitive di base sono AC-1, ovvero response-side payload injection, in cui il router riscrive gli argomenti JSON di una tool-call dopo che il modello ha risposto ma prima che il client la esegua, e AC-2, ovvero passive secret exfiltration, in cui il router si limita a leggere il traffico e a conservare asincronamente chiavi API, PAT GitHub, token AWS, chiavi private Ethereum, chiavi PEM.

A queste si aggiungono due varianti di evasione adattiva. AC-1.a (dependency-targeted injection) sostituisce nel comando di installazione un nome di pacchetto legittimo con un typosquat preregistrato su PyPI o npm, lasciando invariato il resto della riga di comando e ingannando così le approval UI basate sui domini. L’esempio che figura nel paper è istruttivo: pip install requests
viene riscritto in pip install reqeusts
, una singola lettera invertita, un pacchetto preregistrato dall’attaccante, una dipendenza che viene memorizzata nella cache locale e reimportata in ogni sessione futura.

Un foothold di supply chain durevole ottenuto in uno scambio JSON. AC-1.b (conditional delivery) attiva la riscrittura solo quando un predicato di sessione è verificato: dopo N richieste benigne, per client in modalità autonoma (cosiddetta YOLO, in cui l’agente esegue i tool senza chiedere conferma comando per comando), in determinate finestre orarie o per progetti scritti in linguaggi target. Il predicato vive server-side, è opaco al client, e rende strutturalmente inadeguato qualunque audit black-box di lunghezza finita.

Il punto architetturale, sottolineano gli autori, è che questi attacchi sono ortogonali alla prompt injection: non modificano il ragionamento del modello, agiscono sul layer JSON a valle dell’inferenza. Si compongono con le difese lato modello anziché sostituirle.

Vulnerabilità reali: cosa succede dentro i router LLM

Il dataset combina due popolazioni. La prima è costituita da 28 router a pagamento acquistati da Taobao, Xianyu e vetrine Shopify, mercati dove, come documentato da inchieste precedenti di ChinaTalk, alcuni negozi accumulano oltre 30 000 ordini ripetuti solo per la rivendita di accesso API. La seconda è composta da 400 router gratuiti raccolti da community pubbliche, link in chiaro e dump di configurazione. La maggior parte è costruita sui due template open source più diffusi, sub2api (circa 11 000 stelle su GitHub) e new-api (25 400 stelle, 1,25 milioni di pull da Docker Hub), il cui fork a monte one-api ne conta altre 30 500 con 1,19 milioni di pull.

Testati con una pipeline automatizzata che genera tool-call realistiche a partire da TerminalBench 2.0 e le esegue in sandbox monitorate, i numeri sono i seguenti: 1 router a pagamento e 8 gratuiti iniettano attivamente codice malevolo nelle risposte, riscrivendo comandi o dipendenze prima della consegna al client; 17 router gratuiti generano attività AWS successiva attribuibile a credenziali canary di ricerca osservate in transito; 1 router drena ETH da una chiave privata Ethereum predisposta come esca.

Due router implementano già in produzione logiche di evasione adattiva: uno attiva la riscrittura solo dopo cinquanta chiamate pulite, un altro la riserva a sessioni in modalità YOLO e a progetti scritti in Rust o Go. Logica operativa, non esotica, sufficiente a lasciar passare puliti gli smoke test superficiali e a eseguire il rewrite solo su sessioni di alto valore.

Caso LiteLLM: il primo grande attacco alla supply chain AI

La parte più inquietante è che uno scenario analogo è già avvenuto alla scala di un progetto di riferimento. Tra le 10:39 UTC e le 16:00 UTC del 24 marzo 2026, due versioni compromesse del pacchetto Python litellm, la 1.82.7 e la 1.82.8, sono rimaste pubblicate su PyPI, caricate direttamente dal gruppo noto come TeamPCP dopo aver ottenuto le credenziali PyPI del maintainer attraverso una precedente compromissione di Trivy, lo scanner di vulnerabilità open source usato nella CI/CD di LiteLLM stessa.

La campagna complessiva è tracciata dal CVE-2026-33634 (CVSS v4.0 Base 9,4, CVSS v3.1 Base 8,8, CWE-506 Embedded Malicious Code), formalmente assegnato alla vulnerabilità di Trivy che ha fatto da testa di ponte, e successivamente inserita dalla CISA nel catalogo Known Exploited Vulnerabilities.

I pacchetti LiteLLM contenevano un credential stealer embedded nel file proxy_server.py ed esfiltravano verso un dominio di typosquatting (models.litellm[.]cloud); la versione 1.82.8 aggiungeva inoltre un file litellm_init.pth che veniva eseguito a ogni invocazione dell’interprete Python sull’host, indipendentemente dall’import esplicito di LiteLLM. Endor Labs ha descritto il payload come un credential harvester su chiavi SSH, credenziali cloud, secret Kubernetes, wallet di criptovaluta e file .env, accompagnato da un toolkit di lateral movement Kubernetes e da una backdoor systemd persistente (sysmon.service).

I clienti di LiteLLM Cloud e quelli che usavano l’immagine Docker ufficiale LiteLLM Proxy non sono stati impattati, perché quelle pipeline pinnano le dipendenze in requirements.txt
; a essere colpiti sono stati chi ha eseguito pip install litellm
senza pin di versione nella finestra di esposizione e chi aveva LiteLLM come dipendenza transitiva non pinnata, ad esempio tramite framework di agenti, server MCP o orchestrator LLM.

LiteLLM non è un caso limite: secondo i dati riportati da Snyk e Zscaler ThreatLabz, il pacchetto viene scaricato circa 3,4 milioni di volte al giorno ed è integrato nelle pipeline di produzione di migliaia di organizzazioni. Wiz, nella propria analisi dell’incidente, riporta che litellm è presente nel 36 per cento di tutti gli ambienti cloud osservati. L’episodio ha dimostrato, in un contesto produttivo reale, esattamente la primitiva su cui il paper UCSB costruisce il suo threat model: una volta compromesso il pipeline delle richieste di un router ampiamente deployato, ogni tool-call, chiave API e prompt di sistema in transito è esposto alla riscrittura o all’estrazione, senza necessità di rompere il TLS o i pesi del modello.

Perché anche i router “sicuri” possono essere compromessi

Il cuore politico del paper è però la terza sezione empirica: i due studi di poisoning. L’idea è che i router apparentemente benigni possano essere trascinati nello stesso perimetro di attacco non perché cambi il gestore, ma perché la catena a monte viene inquinata.

Nel primo esperimento i ricercatori hanno pubblicato intenzionalmente una chiave OpenAI di ricerca su forum cinesi, gruppi WeChat e Telegram frequentati da operatori di relay. Una sola chiave ha processato cento milioni di token GPT-5.4 e più di sette sessioni Codex distinte. In almeno una di quelle sessioni, precisano gli autori, sono state osservate più credenziali distinte transitare dietro la stessa chiave condivisa; un pattern compatibile sia con il riuso diretto da parte dell’operatore del router sia con il riuso all’interno di una catena di relay più lunga.

Nel secondo esperimento il team ha deployato decoy volutamente deboli: istanze claude-relay-service vulnerabili su venti domini, e istanze Sub2API e CLIProxyAPI con password deboli su venti indirizzi IP. I decoy hanno ricevuto oltre 40 000 tentativi di accesso non autorizzati da 147 IP distinti con sei fingerprint JA3 unici, hanno servito circa due miliardi di token GPT-5.4 e 5.3-codex, hanno esposto all’incirca tredici gigabyte di traffico downstream in chiaro e hanno raccolto 99 credenziali distinte su 440 sessioni Codex e 398 progetti o host.

Qui arriva il dato che dovrebbe interessare chiunque si occupi di governance dell’IA generativa in azienda. Di quelle 440 sessioni, tutte esponevano almeno un percorso di esecuzione shell riscrivibile, e 401 giravano già in modalità YOLO, cioè con l’auto-approvazione dei tool attivata lato client. Per 401 sessioni su 440, l’AC-1.b sofisticato con predicati di sessione non sarebbe nemmeno servito: sarebbe bastata la versione più grezza dell’iniezione di payload. L’autonomia del client, in altre parole, è già da sola la superficie di attacco.

Come difendersi dagli attacchi AI oggi

Gli autori implementano anche Mine, un proxy di ricerca che porta in produzione tutte e quattro le classi di attacco contro quattro framework pubblici (OpenClaw, OpenCode, Codex di OpenAI, Claude Code di Anthropic) e, soprattutto, tre difese immediatamente deployabili senza cooperazione del provider. Mine non viene distribuito pubblicamente: nell’appendice etica gli autori motivano la scelta come una valutazione classica di ricerca dual-use.

La prima difesa è un policy gate fail-closed sui tool ad alto rischio: blocca ogni campione AC-1 e AC-1.a del benchmark sintetico con un tasso di falsi positivi dell’1 per cento e un costo di decisione mediano di 2,3 microsecondi. Difesa robusta sul perimetro comportamentale ingenuo, ma non a prova di avversario consapevole: sullo stesso benchmark, se l’attaccante ospita il payload su un dominio già in allowlist o pre-posiziona uno stager locale da richiamare in seguito, il gate viene bypassato nel cento per cento dei casi. Lo si consideri quindi un filtro grossolano per i workflow più ovvi, non una linea di difesa completa.

La seconda è una anomaly detection sulle risposte, basata su Isolation Forest e cinque feature (punteggio di rischio shell, frequenza del tool nella sessione, entropia degli argomenti, pattern sospetti di secret, deviazione dallo schema). A un budget di falsi positivi del 6,7 per cento intercetta l’89 per cento dei payload AC-1, il 50 per cento degli AC-1.a e circa il 51 per cento degli AC-1.b. Utile come strumento di prioritizzazione della review, non come gate di blocco. L’ablation presentata nell’appendice mostra che il grosso del segnale deriva dal punteggio di rischio shell: rimuoverlo fa precipitare la detection di AC-1 al 17,6 per cento, a conferma che il detector è essenzialmente un filtro sintattico specializzato su una classe di comandi.

La terza è un log di trasparenza append-only che registra body di richiesta e risposta, URL del router, metadati TLS e hash dei byte grezzi della risposta dopo redazione dei secret. Non previene nulla, ma costa circa 12 MB ogni mille sessioni (1,26 KB per entry) e consente, a posteriori, di delimitare l’esposizione quando una chiave o un operatore vengono considerati sospetti. È il tipo di controllo che, nell’ottica di un SOC, chiude il ciclo di incident response senza cambiare il modello di fiducia.

Il limite attuale della sicurezza AI: manca la verifica delle risposte

Nessuno di questi tre controlli autentica l’origine. Un router che si mantenga all’interno degli allowlist locali e sappia evitare pattern troppo evidenti può comunque alterare la semantica dei tool-call senza che il client abbia modo di accorgersene. La conclusione degli autori è esplicita: chiudere la falla richiede una busta firmata dal provider, un oggetto JSON canonicalizzato (nell’appendice C del paper ne è proposta una struttura ispirata a DKIM, RFC 6376, e alla canonicalizzazione JCS di RFC 8785) che contenga identità del provider, modello, contenuto, tool-call con argomenti nativi, nonce del client, finestra di validità e firma Ed25519. Nessun provider di tool-use e nemmeno la specifica MCP attuale espongono oggi un meccanismo simile.

Sicurezza informatica aziende: cosa fare subito

Fino a quando quel meccanismo non esisterà, la conseguenza operativa per CISO, CTO e team DevSecOps è immediata. Il trust boundary reale di un agente LLM non coincide con il router che l’utente ha scelto di configurare: coincide con il più debole router presente nell’intera catena a valle, con ogni credenziale precedentemente trapelata che qualcuno lungo quella catena stia ancora riutilizzando e con il livello di autonomia che il client ha lasciato attivo. Una sessione YOLO su un endpoint gratuito pescato in un gruppo Telegram non è un power user che sa quel che fa: è una superficie di attacco su cui, alla luce dei dati appena pubblicati, è già stato scritto abbastanza per non considerarla più teorica.

Sul piano delle policy aziendali, il paper suggerisce alcune scelte che difficilmente potranno essere rimandate a lungo. L’inventario degli endpoint LLM effettivamente usati da sviluppatori e agenti interni va fatto con lo stesso rigore con cui si inventariano i provider cloud, e non può fermarsi al router di primo livello: deve seguire, dove possibile, l’intera catena di relay.

Le modalità autonome dei coding agent richiedono un contenimento attivo, ovvero sandbox, devcontainer o macchine dedicate con accesso di rete limitato a una lista di host fidati; questo è del resto anche l’orientamento esplicitato da Anthropic nella propria documentazione «Safe YOLO» per Claude Code, che raccomanda l’uso di --dangerously-skip-permissions
solo all’interno di container senza accesso a Internet. Le chiavi che transitano sui router non devono essere a lunga durata: sono token scoped a scadenza breve, ruotati su incidente e, dove il vendor lo supporta, emessi per singolo task.

E per i tool a più alto rischio, quelli che chiamano Bash, run_command
, pip install
, npm install
, cargo add
, un policy gate lato client con allowlist esplicita di domini e pacchetti è, pur con tutti i suoi limiti, un investimento dall’ottimo rapporto costo-beneficio rispetto alle alternative odierne.

Conclusione: la nuova frontiera degli attacchi AI

Il messaggio di fondo del lavoro di Liu e colleghi è che la supply chain degli agenti LLM non comincia al provider del modello e non finisce al client: passa per uno strato di intermediari che oggi il mercato tratta come trasporto trasparente e che, per come è fatto, non può esserlo. Renderlo verificabile è un problema di standard, non di buone pratiche.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/sicurezza-ai-router-llm/




E-evidence, l’Italia chiude il cerchio: cosa cambia davvero con i d.lgs. 215 e 216 del 2025

Con i decreti legislativi 30 dicembre 2025, n. 215 e n. 216, pubblicati nella Gazzetta Ufficiale n. 11 del 15 gennaio 2026, l’Italia ha imboccato il tratto finale di attuazione del pacchetto europeo sulle prove elettroniche (E-evidence). Due testi, due tempi, un unico obiettivo: rendere operativo sul territorio nazionale un modello di acquisizione transfrontaliera dei dati digitali che, dal 18 agosto 2026, cambierà in modo strutturale il rapporto fra autorità giudiziarie, prestatori di servizi e cittadini. Il 7 aprile 2026, a poche settimane dall’operatività, l’Ufficio del Massimario della Corte di Cassazione ha pubblicato la Relazione n. 25/2026, a firma della dott.ssa Caterina Brignone, che offre la prima lettura sistematica del quadro attuativo nazionale.

La posta in gioco si misura con un dato ricorrente nei documenti della Commissione europea: circa l’85% delle indagini penali nell’Unione coinvolge prove elettroniche, e in una quota significativa dei casi quei dati sono conservati in uno Stato diverso da quello in cui il reato è stato commesso. Fino a ieri, per raggiungerli, le procure dovevano attivare canali di assistenza giudiziaria lenti e spesso scoordinati. L’e-evidence package nasce per scardinare questa asimmetria fra la velocità del dato e la lentezza del diritto.

Due pilastri europei, scadenze a incastro

Il pacchetto si compone del regolamento (UE) 2023/1543 e della direttiva (UE) 2023/1544, entrambi del 12 luglio 2023 e pubblicati nella Gazzetta Ufficiale dell’Unione il 28 luglio dello stesso anno. La scelta di procedere con un doppio strumento riflette una divisione del lavoro precisa: da un lato le regole di procedura, direttamente applicabili negli ordinamenti nazionali; dall’altro l’architettura di compliance imposta ai prestatori di servizi, che richiede interventi adattivi di ciascuno Stato membro. È un tassello di quella più ampia convergenza normativa europea in materia di sicurezza digitale in cui si inseriscono anche NIS2, DORA e CER.

Il cuore operativo del regolamento sono due strumenti giudiziari, destinati a entrare nel lessico quotidiano degli operatori: l’ordine europeo di produzione (EPOC) e l’ordine europeo di conservazione (EPOC-PR). Il primo consente all’autorità giudiziaria di uno Stato membro di richiedere direttamente al fornitore di servizi, anche se stabilito altrove nell’Unione, la trasmissione di dati elettronici già esistenti. Il secondo ha funzione preservativa: impone al provider di congelare i dati per un massimo di sessanta giorni, prorogabili di ulteriori trenta, in attesa di un successivo ordine di produzione o di una rogatoria. I tempi di risposta sono stringenti: dieci giorni in via ordinaria, otto ore nei casi di emergenza.

La direttiva, dal canto suo, costringe ogni prestatore che offre servizi nell’Unione a dotarsi di un interlocutore fisico nel territorio UE, sotto forma di stabilimento designato o di rappresentante legale. Senza questa figura, gli ordini europei non avrebbero un destinatario certo e il meccanismo si svuoterebbe di efficacia.

Le scadenze europee si muovono su due livelli da non confondere: entro il 18 febbraio 2026 gli Stati membri devono recepire la direttiva e notificare alla Commissione le disposizioni sulle sanzioni; entro il 18 agosto 2026 devono essere rese operative le designazioni da parte dei prestatori che offrono servizi nell’Unione a quella data, mentre i nuovi provider dispongono di sei mesi dall’avvio dell’attività (articolo 3, paragrafo 6 della direttiva).

La data del 18 agosto 2026 coincide, non a caso, con la data di applicazione del regolamento (articolo 34, paragrafo 2). Il regolamento, entrato in vigore il 18 agosto 2023, diventa quindi pienamente operativo tre anni dopo, in un sistema finalmente completo di destinatari.

Il doppio binario italiano: prima il “chi”, poi il “come”

La legge di delegazione europea 2024, legge 13 giugno 2025, n. 91, ha programmato l’implementazione disegnando un cronoprogramma simmetrico a quello dei due strumenti europei. Agli articoli 7 e 19 ha introdotto principi e criteri direttivi per il recepimento, rispettivamente, della direttiva e del regolamento.

Il Governo ha scelto una via a due tappe: un primo decreto, il 215/2025, orientato a rispettare la scadenza del 18 agosto 2025, data entro la quale gli Stati membri dovevano notificare alla Commissione le autorità competenti ex articolo 31 del regolamento; un secondo decreto, tuttora in iter (lo schema è stato approvato in esame preliminare dal Consiglio dei Ministri il 22 dicembre 2025), che completerà l’adeguamento dell’ordinamento interno. In parallelo, il d.lgs. 216/2025 ha recepito la direttiva, fissando sul suolo italiano il perimetro degli obblighi a carico dei prestatori.

Il d.lgs. 215/2025, a seguito della pubblicazione in Gazzetta Ufficiale del 15 gennaio 2026, è entrato in vigore il 30 gennaio 2026. La Relazione dell’Ufficio del Massimario della Cassazione articola la propria analisi in tre parti: quadro europeo della prova digitale, attuazione nazionale del pacchetto con il modello processuale degli ordini europei, ricadute organizzative e prospettive di sistema. Una lettura di riferimento, destinata a orientare la prassi nei mesi che precedono l’ingresso a regime del meccanismo, che si affianca al primo commento di Claudio De Lazzaro già circolato in dottrina.

D.lgs. 216/2025: il pre-requisito di sistema

Il primo decreto legislativo che conviene leggere, dal punto di vista dei provider, non è il 215 ma il 216. Stabilisce infatti la condizione abilitante di tutto ciò che verrà dopo: senza stabilimento designato o rappresentante legale, nessun ordine europeo potrà essere legittimamente ricevuto ed eseguito.

L’obbligo grava su una platea ampia: operatori di comunicazione elettronica, registrar di nomi di dominio, assegnatari di numerazione IP, prestatori di servizi della società dell’informazione che consentono comunicazioni fra utenti o ne conservano i dati.

In termini concreti: cloud provider, piattaforme di messaggistica, social network, servizi over-the-top, fornitori di hosting, marketplace e simili. Sono invece espressamente esclusi dall’ambito di applicazione i prestatori di servizi finanziari (banche, assicurazioni, intermediari, servizi di pagamento, consulenza sugli investimenti), che non saranno quindi chiamati a designare stabilimenti o a nominare rappresentanti ai fini del pacchetto e-evidence, e non potranno essere destinatari di EPOC o EPOC-PR. Una scelta non priva di conseguenze, che riflette la decisione del legislatore europeo di tenere il comparto finanziario al riparo da questo circuito, in attesa di strumenti dedicati.

L’autorità centrale nazionale, quella a cui i prestatori devono notificare l’avvenuta designazione, è stata individuata nel Ministero dell’interno e, in particolare, nell’organo per la sicurezza e la regolarità dei servizi di telecomunicazione di cui all’articolo 7-bis del decreto-legge 144/2005, convertito dalla legge 155/2005. La notifica va effettuata entro trenta giorni dalla designazione o nomina; i dati di contatto e la lingua accettata saranno poi pubblicati sul sito della rete giudiziaria europea in materia penale e sul portale del Ministero della giustizia. Per un approfondimento sull’articolato del decreto rinviamo al dossier del Senato sull’Atto del Governo n. 330.

Il decreto chiude il cerchio con due previsioni che meritano attenzione: la responsabilità solidale fra prestatore, stabilimento designato e rappresentante legale in caso di inottemperanza, pensata per impedire il rimpallo di responsabilità fondato sull’asserita mancanza di procedure interne adeguate; e un regime sanzionatorio speciale, regolato dall’articolo 7, che si affianca e non si sovrappone alle sanzioni penali eventualmente applicabili. Un’architettura che, sul piano della compliance, impone al prestatore di trattare la figura del rappresentante legale non come un adempimento formale, ma come nodo critico del proprio modello organizzativo.

D.lgs. 215/2025: chi emette, chi riceve, chi controlla

Il 215 è il decreto che traccia la mappa delle autorità italiane coinvolte, sia in fase attiva (emissione) sia in fase passiva (ricezione ed esecuzione di ordini provenienti da altri Stati membri). La relazione illustrativa al Senato chiarisce che si tratta di un primo step di implementazione, concepito per rispettare la scadenza di notifica alla Commissione e in attesa del decreto complementare.

La logica di fondo ricalca fedelmente la graduazione delle garanzie prevista dal regolamento, che distingue quattro categorie di dati lungo una scala di invasività crescente:

  • dati relativi agli abbonati (articolo 3, punto 9);
  • dati richiesti al solo scopo di identificare l’utente (punto 10);
  • dati relativi al traffico (punto 11);
  • dati relativi al contenuto (punto 12).

Alle prime due categorie corrispondono garanzie più snelle; alle ultime due, presidi più rigorosi. Il decreto traduce questa scala nel linguaggio del processo penale italiano. Nel corso delle indagini preliminari, per gli ordini di produzione relativi ai dati degli abbonati e di identificazione provvede il pubblico ministero; per i dati di traffico e di contenuto, il giudice per le indagini preliminari. Per l’ordine di conservazione, trattandosi di un “congelamento” preliminare e non di un’apprensione, provvede sempre il pubblico ministero in via esclusiva, qualsiasi sia la natura del dato.

Nei casi di emergenza, definiti all’articolo 3, punto 18 del regolamento come situazioni di minaccia imminente alla vita, all’integrità fisica o a un’infrastruttura critica, gli ufficiali di polizia giudiziaria possono emettere l’ordine con efficacia immediata, trasmettendolo al pubblico ministero entro quarantotto ore per la convalida, a sua volta da adottare entro le successive quarantotto ore con decreto motivato.

Per le fasi successive alle indagini preliminari, la competenza coincide con quella del giudice che procede, su richiesta del pubblico ministero, della persona offesa, dell’indagato, dell’imputato o delle parti private. Il regolamento consente infatti anche alla difesa di sollecitare l’emissione di un EPOC, aprendo uno spazio nuovo di iniziativa difensiva che, a regime, potrebbe modificare in profondità la geografia dell’acquisizione della prova digitale nel procedimento penale.

Un presidio di sistema non marginale è la clausola di inutilizzabilità sancita all’articolo 2, comma 7: i dati acquisiti con un ordine europeo di produzione emesso fuori dai casi o in mancanza delle condizioni previste dal regolamento e dal decreto non possono essere utilizzati nel procedimento.

La “procedura accelerata”: una novità senza precedenti

Uno dei profili più interessanti del 215 è l’articolo 4, che introduce una procedura accelerata destinata a operare fuori dai casi di emergenza tipici definiti dal regolamento, ma in situazioni d’urgenza che impongono comunque una decisione tempestiva. Secondo la stessa relazione illustrativa, si tratta di un modulo che non trova precedenti nella legge processuale nazionale.

Il meccanismo è quello della previa convalida: il pubblico ministero (per ottenere i dati di traffico o di contenuto) o l’ufficiale di polizia giudiziaria (per i dati degli abbonati e di identificazione) emette l’ordine, la cui efficacia è però sospesa fino alla convalida dell’autorità superiore. L’ordine è trasmesso entro ventiquattro ore dall’emissione; il giudice per le indagini preliminari (nel primo caso) o il pubblico ministero (nel secondo) decide sulla convalida entro le successive quarantotto ore.

Un’architettura che si distingue per tempistiche da quella della procedura d’emergenza, disegnata con un modulo 48+48. La base normativa si rinviene nell’articolo 4, paragrafo 1, lettera b) e paragrafo 2, lettera b) del regolamento, che lascia agli Stati margine di manovra per definire autorità e procedure in casi urgenti. L’Italia ha sfruttato questo spazio per disegnare un percorso speditivo destinato a coprire quella zona grigia in cui l’emergenza tipizzata non sussiste, ma l’attesa dei tempi ordinari rischierebbe di compromettere l’indagine.

Coordinamento investigativo: DNA, Procura generale, Eurojust

Il decreto non trascura il profilo del coordinamento. Quando l’ordine riguarda delitti rientranti nella competenza distrettuale rafforzata (articoli 51, commi 3-bis e 3-quater, e 371-bis, comma 4-bis, c.p.p., nonché i delitti di cui all’articolo 118-bis delle norme di attuazione del codice di procedura penale), copia del certificato EPOC o EPOC-PR è trasmessa alla Procura nazionale antimafia e antiterrorismo o al Procuratore generale presso la Corte d’appello. Dove operino i meccanismi di coordinamento europeo, l’informazione è trasmessa anche al membro nazionale di Eurojust, ai sensi dell’articolo 21, paragrafo 5 del regolamento (UE) 2018/1727.

È una previsione tutt’altro che marginale. Per la prima volta, un flusso investigativo digitale così denso di dati, spesso relativi a soggetti stranieri o transnazionali, viene canalizzato fin dall’origine verso gli organi di coordinamento nazionali ed europei. Per i CISO delle aziende destinatarie di ordini, questo significa che ogni EPOC ricevuto potrebbe avere, a monte, un’operazione di respiro europeo di cui il prestatore è solo una tessera.

Fase passiva: chi riceve gli ordini stranieri

Simmetricamente, il 215 disciplina la competenza interna per la ricezione e l’esecuzione di ordini emessi da autorità di altri Stati membri. La scelta del legislatore è quella della procura distrettuale: è il procuratore della Repubblica presso il tribunale del capoluogo del distretto in cui lo stabilimento designato o il rappresentante legale sono stabiliti a ricevere le notifiche e a gestire l’esecuzione degli ordini di produzione per dati abbonati e identificativi e degli ordini di conservazione. Per gli ordini di produzione relativi a dati di traffico o di contenuto la competenza si sposta sul GIP dello stesso tribunale, coerentemente con la graduazione delle garanzie.

Quanto alla trasmissione amministrativa degli ordini e delle notifiche, l’articolo 5 individua nel Ministero della giustizia l’autorità centrale cui fare riferimento ai sensi dell’articolo 4, paragrafo 6 del regolamento.

Per gestire l’articolo 17 del regolamento, che regola i casi in cui il prestatore solleva un’obiezione motivata per contrasto con obblighi di diritto di un paese terzo, il decreto individua due percorsi alternativi di riesame: il tribunale del riesame delle misure reali se l’ordine è stato emesso o convalidato dal giudice, il GIP se è stato emesso o convalidato dal pubblico ministero.

L’onda lunga sul diritto interno: art. 132 Codice Privacy e il nuovo art. 263-bis c.p.p.

Forse il segmento più sottovalutato del 215, ma quello con l’impatto sistemico più ampio, è l’articolo 9. Qui il legislatore ha compiuto una serie di interventi di coordinamento sull’ordinamento interno, con due effetti principali.

Il primo riguarda l’articolo 132 del Codice Privacy (d.lgs. 196/2003), la disposizione cardine sulla conservazione e l’acquisizione del traffico telefonico e telematico.

Il testo viene riscritto in più punti: si introduce la possibilità di acquisire i dati di traffico anche per agevolare le ricerche di un latitante condannato con sentenza definitiva a pena non inferiore a quattro mesi, in coerenza con l’articolo 5 del regolamento; si estende il potere di ordinare la conservazione dei dati al pubblico ministero, che diventa così titolare di uno strumento “domestico” simmetrico all’EPOC-PR europeo; si uniforma la disciplina dei dati telefonici e telematici, eliminando un’asimmetria del vecchio comma 4-ter non più giustificata. Il parere del Garante Privacy del 25 settembre 2025 aveva già auspicato questo coordinamento, sottolineando la necessità di evitare fratture fra disciplina europea e disciplina domestica della data retention.

Il secondo intervento è l’introduzione di un nuovo articolo nel codice di procedura penale, il 263-bis c.p.p., che disciplina la conservazione dei dati relativi al contenuto, la categoria che l’articolo 132 del Codice Privacy, per sua vocazione, non copriva. Il pubblico ministero può ordinarne la conservazione; la polizia giudiziaria può provvedervi in via d’urgenza, con convalida successiva. Per la prima volta l’ordinamento italiano ha uno strumento nominato e disciplinato per “congelare” i contenuti delle comunicazioni in attesa dell’acquisizione vera e propria, saldando un vuoto che, nella prassi, veniva coperto con strumenti atipici e non sempre solidi in fase dibattimentale.

Che cosa devono fare, in concreto, i provider

Per i responsabili della sicurezza e i legal compliance manager delle aziende che offrono servizi in UE, il calendario si è fatto serrato. Tre sono i fronti da presidiare entro l’estate del 2026.

Il primo è organizzativo: individuare o costituire uno stabilimento designato nell’Unione (se il gruppo vi ha sede) oppure nominare un rappresentante legale. La scelta non è neutra: il rappresentante andrà dotato di poteri e risorse effettive per rispondere a ordini con scadenze di dieci giorni, o di otto ore in emergenza. Significa processi interni, playbook di risposta, SLA con il resto del gruppo, procedure di escalation.

Il secondo è tecnologico: collegarsi al sistema informatico decentrato, istituito dall’articolo 19 del regolamento, attraverso cui transiteranno in forma elettronica tutti gli ordini, i moduli EPOC ed EPOC-PR e i dati richiesti. Gli atti di esecuzione che ne definiscono le specifiche tecniche sono previsti dall’articolo 25, e l’obbligo di utilizzare il sistema decorre un anno dopo la loro adozione. I costi di integrazione gravano sui prestatori; le opportunità di rimborso previste dall’articolo 14 riguardano le spese di esecuzione, non quelle infrastrutturali, e sono subordinate alla disciplina interna dello Stato di emissione. La tempistica di otto ore per le emergenze richiede processi automatizzati di ricerca, estrazione e trasmissione dei dati, non improvvisazioni.

Il terzo è di data governance: mappare con precisione le categorie di dati detenute (abbonati, identificativi, traffico, contenuto) secondo la tassonomia dell’articolo 3 del regolamento, e garantire la capacità di rispondere selettivamente. Un’acquisizione indifferenziata esporrebbe l’azienda sia al rischio di contestazioni in sede di riesame europeo sia a profili GDPR tutt’altro che banali.

Il calendario che conta

Per orientarsi, sintetizziamo le date chiave:

  • 15 gennaio 2026: pubblicazione in Gazzetta Ufficiale dei d.lgs. 215 e 216/2025;
  • 30 gennaio 2026: entrata in vigore del d.lgs. 215/2025;
  • 18 febbraio 2026: scadenza per il recepimento della direttiva 2023/1544 da parte degli Stati membri e per la notifica alla Commissione delle disposizioni sanzionatorie;
  • 7 aprile 2026: pubblicazione della Relazione n. 25/2026 dell’Ufficio del Massimario della Corte di Cassazione;
  • 18 agosto 2026: termine entro cui i prestatori di servizi che offrono servizi nell’Unione devono aver designato lo stabilimento o nominato il rappresentante legale, e contestuale data di applicazione del regolamento 2023/1543. Per i nuovi prestatori che iniziano a offrire servizi dopo il 18 febbraio 2026, il termine è di sei mesi dall’avvio dell’attività.

In mezzo, un secondo decreto legislativo, complementare al 215, è atteso per completare il quadro. L’Italia, a quel punto, sarà uno dei ventisette nodi attivi di un sistema di cooperazione giudiziaria che, per la prima volta, azzera le distanze fra autorità inquirente e prestatore, ovunque questo sia stabilito in Europa. Un’infrastruttura giuridica che, se funzionerà come progettata, ridefinirà in profondità il modo in cui si costruisce la prova digitale nel procedimento penale. Se non funzionerà, resterà comunque il cambiamento più ambizioso tentato dall’Unione in materia di cooperazione penale dall’ordine di indagine europeo in poi.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-crime/e-evidence-italia-d-lgs-215-216/




Gestire il rischio cyber oggi: il modello Cyber Resilience Lifecycle di ReeVo

Il Cyber Resilience Lifecycle di ReeVo ridisegna la gestione del rischio cyber nel momento in cui le certezze su cui si reggeva la sicurezza informatica stanno cedendo una dopo l’altra. Non è una provocazione: è la logica conseguenza di un cambiamento che molti hanno visto arrivare, ma che pochi hanno saputo anticipare davvero.

Per anni il paradigma dominante ha risposto alle minacce con più controlli, più policy, più layer tecnologici. Un accumulo progressivo di difese che, però, continuava a ragionare in modo lineare in un mondo diventato radicalmente non lineare. Gli attaccanti evolvono, si adattano, imparano dagli errori altrui. Le organizzazioni, troppo spesso, no.

La vera domanda, allora, non è più se un attacco arriverà, ma quanto velocemente si sarà in grado di riconoscerlo, contenerlo e trasformarlo in un’informazione utile per il futuro. Resilienza, non invulnerabilità: un cambio di paradigma che suona semplice, ma che richiede metodo, visione e continuità. Perché nel panorama attuale, sopravvivere a un incidente non basta: bisogna uscirne più forti di prima, con una postura di sicurezza più matura e consapevole dei propri punti critici.

Il Cyber Resilience Lifecycle di ReeVo: un approccio integrato e continuo alla gestione del rischio cyber

Negli ultimi anni il cybercrime ha superato i confini tradizionali, trasformandosi in un fenomeno sempre più pervasivo e strutturato, nel quale criminalità organizzata, dinamiche geopolitiche e tecnologie emergenti si intrecciano. Gli attacchi informatici non sono più eventi isolati, ma operazioni sofisticate, spesso automatizzate e condotte su larga scala, capaci di colpire indistintamente aziende di ogni dimensione e settore. In questo scenario, la cybersecurity non può più fondarsi su un approccio statico, basato su controlli rigidi e limitato ad attività di compliance, ma deve evolvere in un processo continuo e adattivo di gestione del rischio.

Da questa esigenza nasce il Cyber Resilience Lifecycle sviluppato da ReeVo, un modello dinamico progettato per accompagnare le organizzazioni in un percorso di miglioramento continuo della propria postura di sicurezza. Non si tratta soltanto di adottare tecnologie avanzate, ma di costruire una strategia integrata, capace di anticipare, affrontare e superare le minacce informatiche in modo strutturato ed efficace.

Il modello si articola in cinque fasi consecutive – Know, Prevent, Detect, Respond e Assess – che coprono l’intero ciclo della cybersecurity. La fase di Know rappresenta il punto di partenza: comprendere il proprio livello di esposizione al rischio è fondamentale per definire priorità e orientare gli investimenti. Questo significa mappare gli asset critici, identificare le vulnerabilità e analizzare le possibili superfici di attacco.

Segue la fase di Prevent, in cui vengono implementate misure di protezione volte a ridurre la probabilità di compromissione. In questa fase rientrano tecnologie, policy e attività di formazione, elementi indispensabili per costruire una prima linea di difesa efficace. La fase di Detect assume un ruolo centrale, poiché consente di individuare tempestivamente eventuali anomalie o comportamenti sospetti.

Quando un incidente si verifica, è essenziale intervenire in modo rapido e coordinato. La fase di Respond si concentra proprio sulla gestione degli attacchi, con l’obiettivo di minimizzare l’impatto operativo e garantire la continuità del business. Infine, la fase di Assess chiude il ciclo attraverso un’attività di valutazione e miglioramento continuo: analizzare quanto accaduto consente infatti di rafforzare le difese e prepararsi meglio alle minacce future.

Il Cyber Resilience Lifecycle è dunque un processo continuo, alimentato costantemente da nuove informazioni, verifiche e adattamenti. In un contesto in cui anche la compliance normativa assume un ruolo sempre più rilevante, adottare un approccio strutturato e proattivo alla sicurezza non è più un’opzione, ma una necessità strategica per garantire resilienza, continuità e competitività nel tempo.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/cyber-resilience-reevo/




AI Act, l’Unione Europea bandisce le “nudify apps”

L’Europa annuncia un passo in avanti sul contrasto al Deepfake Porn: il 26 marzo 2026 il Parlamento UE ha varato una misura che intende colpire le cosiddette nudify apps, nate per generare o alterare immagini di persone reali tramite l’intelligenza artificiale e creare contenuti espliciti senza il loro consenso.

Nello specifico si tratta di un emendamento all’AI Act, parte del più generale processo di revisione noto come Digital Omnibus e avviato nel novembre 2025 allo scopo dichiarato di semplificare e aggiornare la normativa comunitaria alla luce del rapido sviluppo delle tecnologie digitali.

Come già avvenuto in altri campi, l’intelligenza artificiale ha avuto un impatto dirompente anche sulla diffusione di contenuti sessualmente espliciti. Oltre a trasformare l’industria legale dell’intrattenimento per adulti, l’estrema accessibilità degli strumenti che usano l’AI per produrre materiale pornografico a partire da immagini o video di persone inconsapevoli (inclusi minorenni) sta abilitando forme di abuso sempre più pervasive.

Deepfake Porn: un fenomeno in crescita allarmante

Il termine deepfake può indicare ogni tipologia di contenuto audiovisivo digitale creato e/o alterato mediante AI.

Sebbene si tratti di un’attività teoricamente lecita, è noto già da anni come ciò possa prestarsi a numerosi utilizzi illeciti.

Una specifica tipologia è infatti rappresentata dal deepnude, che parte dall’immagine di una persona reale per generarne altre di natura esplicita.
La stragrande maggioranza di tali contenuti rappresenta corpi femminili in scenari sessuali: secondo le Nazioni Unite, “deepfake pornography made up 98% of all deepfake videos online and 99% depicted women, according to a 2023 report”.

Il medesimo report registra una crescita superiore al 500% dei video deepfake circolanti a partire dal 2019, evidenziando quanto gli strumenti necessari a crearli siano ormai “widely available, usually free, and require very little technical expertise”.

Come in altri casi di Technology Facilitated Gender-based Violence (TFGBV) – in particolare nella categoria dell’Image Based Sexual Abuse (IBSA) – una volta pubblicati i contenuti sono quasi impossibili da rimuovere; “once posted, AI generated content can be replicated endlessly, saved to private devices and shared across platforms, making it nearly impossible to fully remove”.

Le persone coinvolte rischiano di soffrire gravi effetti psicologici ed emotivi, nonché professionali e reputazionali, in conseguenza dell’essere state associate a materiali pornografici diffusi online.

Cosa sono le nudify apps?

Nell’ambito del Deepfake Porn, si è sviluppato un fiorente mercato dedicato ad app e software che in poche mosse consentono di “denudare” una persona partendo da un’immagine in cui appaia parzialmente o completamente vestita.

Sebbene tale possibilità esistesse già da diversi anni, la massiccia diffusione di strumenti semplici e gratuiti (o comunque a prezzi molto accessibili) ha trasformato una realtà marginale in un fenomeno dilagante: secondo una ricerca condotta dal Centre for Countering Digital Hate, il solo GROK avrebbe prodotto – in un periodo di osservazione di appena 10 giorni – ben 3 milioni di immagini sessualmente esplicite e 23.000 contenuti relativi ad abusi su minori.

Più di recente, la Internet Watch Foundation (IWF) ha pubblicato i risultati di un’indagine che conferma come nel 2025 siano stati diffusi migliaia di “AI-generated images and videos of realistic child sexual abuse”.

Anche in questo caso, è evidente come la circolazione di immagini a carattere intimo che rappresentano minori reali e riconoscibili rischi di avere effetti devastanti sulla loro sicurezza presente e futura.

Le normative sul Deepfake Porn nel mondo

Mentre la creazione e la diffusione di immagini ritraenti minori sono severamente proibite ovunque, i contenuti che mostrano soggetti adulti sono rimasti a lungo in una “zona grigia” sul piano legale.

Soltanto negli ultimi anni, anche in seguito al clamore mediatico creatosi intorno ad alcune “vittime eccellenti” – come la cantante Taylor Swift – molti Paesi hanno iniziato ad adottare normative per contenere questo fenomeno e sanzionare i responsabili.

Vediamone le principali.

Regno Unito: già dal 2023, l’Online Safety Act proibisce la diffusione di immagini esplicite manipolate digitalmente, senza tuttavia rivolgersi in modo specifico alla creazione di contenuti mediante AI; per colmare tale lacuna, nel 2025 il Data (Use and Access) Act ha previsto come reato “to create or request the creation of non-consensual intimate images”.

Corea del Sud: alla luce di oltre 800 casi in un solo anno, nel 2024 il governo di Seoul ha adottato una delle normative più rigorose al mondo in tema di deepfake, vietando i contenuti espliciti generati tramite AI e prevedendo fino a 3 anni di carcere per chi detenga o visioni tali contenuti, nonché fino a 7 per chi li generi a fini di distribuzione.

Singapore: nello stesso anno sono state introdotte pene severe per i responsabili di truffe o estorsioni conseguenti alla creazione di deepfake a natura sessuale, sulla scorta di numerosi scandali verificatisi nei mesi precedenti.

Stati Uniti: il “Take It Down Act” (Tools to Address Known Exploitation by Immobilizing Technological Deepfakes on Websites and Networks) del 2025 criminalizza la pubblicazione non consensuale di immagini intime, citando esplicitamente i deepfakes; entro il 19 maggio 2026, ogni piattaforma che ospiti contenuti creati dagli utenti deve dotarsi di sistemi per la segnalazione e rimozione di materiali espliciti creati senza il consenso delle persone ritratte.

Messico: sempre nel 2025, il Congresso ha approvato una legge che prevede fino a 5 anni di carcere (e significative sanzioni pecuniarie) per chiunque crei o diffonda senza consenso materiali a contenuto sessuale manipolati tramite l’AI, includendo espressamente ogni applicazione, programma o tecnologia capace di alterare o modificare fotografie, file audio, video o qualsiasi altro materiale grafico.

Brasile: a marzo 2026, il codice penale è stato aggiornato per includere nuove sanzioni nei confronti di chi alteri l’immagine o la voce di una persona mediante l’uso di AI o altre tecnologie; per i siti o piattaforme che consentano la pubblicazione di materiali espliciti così prodotti, sono previste multe fino al 2% del fatturato annuale.

Molti altri Paesi – come l’Australia o il Canada – hanno annunciato di star elaborando simili normative, confermando la percezione globale del Deepfake porn come minaccia concreta ed estremamente attuale.

Anche la nuova UN Cybercrime Convention prevede per gli Stati contraenti l’obbligo di criminalizzare la condivisione di Non-Consensual Intimate Imagery (NCII), includendo le immagini di persone reali create o modificate dall’intelligenza artificiale; e l’Unione Europea aveva già provveduto ad adottare alcune misure di contrasto.

Il divieto di deepnudes: direttiva europea e legge italiana

In effetti la Direttiva (UE) 2024/1385, adottata nel 2024 e dedicata al contrasto della violenza contro le donne, proibisce “creating and distributing pornographic material digitally altered to make it appear that a person is involved without their consent”.

Un’ipotesi che – pur non menzionando esplicitamente gli strumenti basati sull’AI – potrebbe applicarsi anche ai contenuti generati dalle nudify apps.

Tuttavia, come noto, le direttive non sono immediatamente applicabili negli Stati membri; al contrario richiedono passaggi applicativi che non tutti i componenti dell’Unione hanno ancora compiuto, portando a una disparità di tutele tra i vari Paesi UE.

Inoltre la direttiva subordina l’illiceità dei deepfake alla circostanza che siano idonei a provocare seri danni (“likely to cause serious harm”), lasciando un ampio margine interpretativo circa la valutazione di tali requisiti.

Analogamente, in Italia l’art. 612 quater c.p. (introdotto dalla legge n. 132/2025) punisce con la reclusione fino a cinque anni “chiunque cagiona un danno ingiusto ad una persona, cedendo, pubblicando o altrimenti diffondendo, senza il suo consenso, immagini, video o voci falsificati o alterati mediante l’impiego di sistemi di intelligenza artificiale”.

La scelta di mutuare dalla direttiva l’elemento del “danno ingiusto” rischia così di limitare l’applicabilità della norma italiana, lasciando alla vittima l’onere della prova in merito agli effetti dell’abuso.

Ulteriori profili di rischio dei Deepnudes

Oltre alle citate conseguenze psicologiche e reputazionali, un deepfake diffuso sul web può esporre la persona ritratta ad attenzioni indesiderate (e potenzialmente pericolose), mettendo a repentaglio la sua sicurezza fisica ed emotiva.

Ma i deepnude hanno già dimostrato di comportare ulteriori profili di rischio: è il caso delle finte app che promettono di creare gratuitamente materiali erotici, in realtà utilizzate da gruppi cyber criminali per indurre gli utenti a scaricare contenuti malevoli con cui sottrarre le loro credenziali per poi condurre attacchi informatici mirati.

I deepfake possono altresì potenziare i casi di sextortion, dove immagini o video intimi generalmente ottenuti con l’inganno sono utilizzati per ricattare qualcuno al fine di estorcere denaro (di solito in criptovalute) o di farsi inviare ulteriori immagini private, minacciando in caso contrario di pubblicarli online.

E anche laddove i materiali in questione vengano creati o modificati artificialmente, non è difficile immaginare come una persona potrebbe finire per cedere al ricatto sull’onda del timore per la propria reputazione personale e professionale.

Conclusioni: contro il Deepfake abuse serve più consapevolezza

Alla luce dei molteplici profili di rischio evidenziati, nonché della rapidità con cui si evolvono le tecnologie, sembra utopico ipotizzare che il solo strumento normativo – tanto a livello nazionale quanto sovranazionale – possa risultare sufficiente ad arginare il fenomeno deepfake.

Risultano senz’altro utili i tentativi di coinvolgere le aziende nella prevenzione degli abusi basati sull’AI; ma difficilmente i colossi tech rinunceranno ai relativi lauti guadagni, al più limitandosi a prevedere meccanismi di age verification e segnalazione/rimozione dei contenuti illegali che tuttavia, proprio come i rimedi giurisdizionali, intervengono quando il danno si è già verificato.

Allo stesso modo, le possibili contromisure tecniche – come il watermarking delle immagini – rischiano di rivelarsi presto superate dall’evoluzione degli strumenti digitali.

Fondamentale, allora, è impegnarsi nel costruire una cultura del consenso a partire dalle giovani generazioni, creando consapevolezza circa i pericoli e le gravi conseguenze potenzialmente derivanti dalla creazione e diffusione di materiali non consensuali online, affinché lo sviluppo delle tecnologie non divenga sempre più uno strumento per ledere la dignità delle persone.

Profilo Autore

Con una laurea in Giurisprudenza conseguita presso l’Università degli Studi Roma Tre – seguita da un dottorato di ricerca in Economia e Diritto delle Relazioni Internazionali – Irene Salvi è docente in diversi Master e Corsi formativi, nonché giornalista pubblicista e ricercatrice indipendente sul tema dell’intersezione tra diritti individuali, libertà civili e tecnologie digitali.

Dal 2020 è consigliera di una rete internazionale attiva nel contrasto alla violenza di genere; nel 2025 ha partecipato al PRIN-PNRR “Gendering Internet. Violence, Resilience and Empowerment in digital spaces” (GIVRE), condotto dalla Sapienza insieme a Università di Padova e Link University, primo progetto di ricerca sul fenomeno della violenza digitale di genere in Italia.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/ai-act-nudify-apps/




Iran nel cyberspazio: operazioni ibride tra Medio Oriente, infrastrutture OT e Cloud Microsoft 365

L’escalation cyber iraniana del primo trimestre 2026 rivela una strategia a doppio vettore: la compromissione degli ambienti cloud delle organizzazioni israeliane e il sabotaggio di sistemi industriali critici negli Stati Uniti. Un modello operativo che ridefinisce il confine tra guerra cinetica e conflitto digitale.

Quello che emerge dai report pubblicati tra la fine di marzo e i primi giorni di aprile 2026 non è un episodio isolato, ma un pattern operativo strutturato. Check Point Research ha tracciato una campagna di password spraying contro ambienti Microsoft 365 in Medio Oriente, condotta da un threat actor riconducibile all’Iran in tre ondate distinte il 3, il 13 e il 23 marzo 2026, colpendo oltre 300 organizzazioni in Israele e più di 25 negli Emirati Arabi Uniti.

Parallelamente, il joint advisory AA26-097A del 7 aprile 2026, firmato da CISA, FBI, NSA, EPA, Dipartimento dell’Energia e US Cyber Command, ha confermato che attori APT affiliati all’Iran stanno attivamente compromettendo PLC Rockwell Automation/Allen-Bradley esposti su internet nei settori Energy, Water and Wastewater Systems e Government Services negli Stati Uniti, con casi documentati di disruption operativa e perdite finanziarie.

Letti separatamente, i due filoni potrebbero sembrare incidenti scollegati. Analizzati insieme, configurano una strategia ibrida di rara coerenza tattica, coerente con quanto già documentato nei 30 giorni di cyber warfare iraniano seguito al 28 febbraio 2026.

Il vettore cloud: 300 organizzazioni israeliane nel mirino

Secondo l’analisi di Check Point Research, la campagna ha colpito oltre 300 organizzazioni israeliane e più di 25 negli EAU, con attività simile osservata contro target in USA, Europa, Regno Unito e Arabia Saudita. Tra i gruppi iraniani noti per questa tecnica figurano Peach Sandstorm e Gray Sandstorm, entrambi con un’ampia storia documentata di password spraying contro ambienti Microsoft 365.

Sul piano dell’attribuzione è importante mantenere la precisione: Microsoft ha valutato che Peach Sandstorm (APT33) opera per conto dell’Islamic Revolutionary Guard Corps (IRGC). Gray Sandstorm (già DEV-0343) è invece descritto come un cluster che agisce verosimilmente a supporto degli interessi iraniani, senza che nei documenti primari pubblici sia stata confermata un’affiliazione esplicita a una specifica agenzia governativa, distinzione rilevante per chi svolge threat intelligence operativa.

Il settore più colpito in Israele è quello municipale, seguito dalla tecnologia (63 tentativi), dalla logistica e trasporti (32), dalla sanità (28) e dal manifatturiero (28). Check Point valuta con moderata confidenza che il targeting delle municipalità israeliane sia correlato alle città colpite da attacchi missilistici iraniani nel corso di marzo, suggerendo che la campagna sia stata progettata per supportare la valutazione dei danni da bombardamento e le operazioni cinetiche in corso.

Sul piano tecnico, il modus operandi è caratterizzato da una sofisticazione deliberatamente contenuta. Durante la fase di scansione, l’attore ha usato nodi Tor exit con rotazione frequente, inviando richieste con un user agent costruito per simulare Internet Explorer 10 su Windows 7. Una volta ottenute credenziali valide, gli attaccanti si autenticano tramite range IP VPN commerciali di Windscribe (185.191.204.X) e NordVPN (169.150.227.X) geolocalizzati in Israele, aggirando le restrizioni geografiche e riducendo il rischio di alert legati ad accessi stranieri.

Il vettore OT: PLC industriali e sistemi SCADA

Secondo l’advisory CISA AA26-097A, almeno da marzo 2026 un gruppo APT affiliato all’Iran ha disrupted il funzionamento di PLC distribuiti in più settori critici statunitensi, tra cui Government Services and Facilities, Water and Wastewater Systems ed Energy. Alcune vittime hanno subito interruzioni operative e perdite finanziarie. Gli attori hanno usato indirizzi IP esteri per accedere a PLC Rockwell Automation/Allen-Bradley esposti su internet, sfruttando software di configurazione legittimi come Studio 5000 Logix Designer per creare connessioni accettate ai dispositivi target, tra cui CompactLogix e Micro850.

Il traffico malevolo è stato osservato sulle porte 44818, 2222, 102, 22 e 502, associate a protocolli OT di diversi vendor, con implicazioni che si estendono potenzialmente oltre i dispositivi Rockwell, inclusi i sistemi Siemens S7 diffusi in Europa e Asia.

Il metodo di accesso non richiede vulnerabilità zero-day: la debolezza sfruttata è di natura architetturale. Come analizzato da Picus Security in relazione all’advisory, i PLC erano esposti su internet senza adeguata segmentazione di rete, controlli di autenticazione o hardening. Le tre azioni difensive più efficaci non richiedono budget: rimuovere le interfacce ICS da internet, cambiare le credenziali di default e bloccare le porte dei protocolli industriali al perimetro.

In un precedente analogo, il gruppo CyberAv3ngers, affiliato all’IRGC Cyber Electronic Command, aveva già compromesso PLC Unitronics nei sistemi idrici statunitensi nel novembre 2023. La campagna attuale rappresenta un’evoluzione di quel playbook su scala maggiore, con dispositivi più diffusi nelle infrastrutture critiche nordamericane. Rockwell Automation aveva già pubblicato il proprio security advisory SD1771 il 20 marzo 2026, esortando i clienti a disconnettere i controller da internet: una linea guida che si allinea quasi perfettamente al messaggio del joint advisory CISA, suggerendo che la campagna fosse già nota al settore privato prima della divulgazione pubblica.

Il ransomware come arma ibrida

Un terzo livello di questa strategia riguarda l’integrazione del ransomware nelle operazioni statali iraniane. Nel marzo 2026, Halcyon ha rivelato che l’amministratore del ransomware Sicarii ha esortato gli operatori filo-iraniani a usare il Baqiyat 313 Locker (BQTlock), attivo con motivazioni pro-palestinesi contro EAU, USA e Israele dal luglio 2025. Secondo Check Point, “le campagne ransomware stanno sfumando il confine tra estorsione criminale e sabotaggio sponsorizzato dallo Stato.”

A fine febbraio 2026, un’organizzazione sanitaria statunitense è stata colpita da Pay2Key, gruppo ransomware iraniano con legami governativi riconducibile al cluster Fox Kitten (noto anche come Lemon Sandstorm, PARISITE, Pioneer Kitten e UNC757). La variante impiegata presenta capacità di evasione e anti-forensics migliorate rispetto alle campagne del luglio 2025. In questo caso non è stata rilevata esfiltrazione di dati, una deviazione dal classico schema del double extortion che suggerisce come l’obiettivo prioritario fosse la disruption operativa più che il guadagno economico.

La dimensione geopolitica: il cyberspazio come teatro del conflitto

Questa campagna non può essere letta al di fuori del suo contesto. Secondo Recorded Future Insikt Group, il targeting della campagna cloud è correlato alle città colpite da missili iraniani, con le operazioni cyber progettate per supportare la valutazione dei danni da bombardamento e le attività cinetiche in corso. Come abbiamo già documentato nell’analisi di Operation Epic Fury e Roaring Lion, il dominio cyber è diventato il secondo fronte attivo del conflitto sin dal 28 febbraio 2026.

Il dato europeo non è trascurabile. Sia la campagna cloud sia il profilo di targeting OT dell’advisory CISA indicano una superficie d’attacco che supera i confini del Medio Oriente. Il targeting di porte associate a protocolli Siemens, Rockwell e Modbus indica che la minaccia è potenzialmente estesa a qualsiasi sistema OT esposto su internet, inclusi quelli capillarmente diffusi nelle infrastrutture critiche europee.

Il quadro macro è confermato dal World Economic Forum: secondo il Global Cybersecurity Outlook 2026, il 64% delle organizzazioni globali tiene oggi conto degli attacchi cyber motivati geopoliticamente nelle proprie strategie di mitigazione del rischio, mentre il 91% delle organizzazioni di maggiori dimensioni ha modificato la propria strategia di cybersecurity in risposta alla volatilità geopolitica.

Implicazioni per le organizzazioni europee e italiane

Il primo livello di rischio riguarda le aziende che operano in settori esposti a tensioni geopolitiche regionali: energia, difesa, trasporti, finanza. Il pattern di targeting iraniano segue logiche di intelligence strategica, non solo di opportunismo, e le organizzazioni europee che hanno rapporti commerciali o tecnologici con i paesi nel mirino possono diventare vettori secondari di accesso.

Il secondo livello riguarda le infrastrutture OT. In Italia, come negli altri paesi europei, la superficie di attacco sui sistemi industriali rimane ampia. La resilienza IT/OT nell’ambito NIS2 impone requisiti di sicurezza più stringenti per i settori critici, ma il percorso di implementazione è ancora in corso per molte organizzazioni. Il Decreto Legislativo 138 del settembre 2024 ha recepito la direttiva in Italia: la semplicità del vettore OT documentato nell’advisory CISA, che non richiede zero-day ma solo PLC accessibili da internet, dovrebbe essere un campanello d’allarme immediato per qualsiasi responsabile della sicurezza operativa.

Il terzo livello riguarda l’identità cloud. Un attacco di password spraying non necessita di malware avanzato per causare danni: una sola password debole può garantire a un avversario un accesso duraturo a un workspace cloud che il personale utilizza quotidianamente. Il monitoraggio delle identità è diventato importante quanto il monitoraggio degli endpoint per le organizzazioni che dipendono da Microsoft 365.

Le contromisure prioritarie

Per gli ambienti cloud Microsoft 365, le misure raccomandate da Check Point Research includono: monitorare i log di accesso per identificare pattern di password spraying con molteplici tentativi falliti da un’unica sorgente; applicare conditional access con geo-fencing e blocco dei nodi Tor; abilitare l’MFA per tutti gli utenti con controlli più stringenti per i ruoli privilegiati; conservare i log di audit per le investigazioni post-compromissione. Il blocco dei range IP associati a Windscribe e NordVPN già noti in questa campagna rappresenta una misura di contenimento efficace nel breve termine.

Per gli ambienti OT, CISA raccomanda di rimuovere immediatamente i PLC dall’esposizione diretta su internet collocandoli dietro gateway sicuri e firewall; per i dispositivi Rockwell, impostare lo switch fisico del controller in modalità run; verificare nei log la presenza di traffico sospetto sulle porte OT, in particolare proveniente da hosting provider esteri; abilitare SSH Dropbear come indicatore di compromissione, dal momento che è stato impiegato dagli attaccanti per mantenere l’accesso remoto ai sistemi compromessi.

Conclusioni: la guerra ibrida è già presente

La campagna iraniana del primo trimestre 2026 è un caso di studio per l’intero settore. Il suo valore analitico non sta nella sofisticazione tecnica, ma nella coordinazione tra vettori multipli e simultanei (cloud M365, PLC/SCADA, ransomware), nella sua integrazione con operazioni cinetiche in corso e nella capacità di proiettare pressione geopolitica ben oltre il teatro di conflitto originario.

Per i professionisti della sicurezza, questo significa che il threat modeling non può più prescindere dalla dimensione geopolitica. Comprendere chi attacca, perché e in quale contesto internazionale è diventato parte integrante della valutazione del rischio, tanto quanto l’analisi delle vulnerabilità tecniche. Il confine tra IT security e national security non è mai stato così sottile.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/iran-cyberspazio-war/




Supply Chain Attack nordcoreano, Contagious Interview prende di mira gli sviluppatori: 1.700 pacchetti malevoli in cinque ecosistemi open source

Un’operazione di supply chain attack attribuita a gruppi hacker nordcoreani ha raggiunto una scala senza precedenti: oltre 1.700 pacchetti malevoli distribuiti contemporaneamente su cinque dei principali registri open source globali, progettati per colpire sviluppatori software in tutto il mondo attraverso strumenti di uso quotidiano. La campagna, denominata Contagious Interview e monitorata dai ricercatori di Socket Security dal 2024, ha compiuto il 7 aprile 2026 un salto qualitativo significativo: per la prima volta, la stessa infrastruttura di staging e gli stessi pattern di distribuzione sono stati replicati in parallelo su npm, PyPI, Go Modules, crates.io e Packagist.

Supply Chain Attack nordcoreano: una fabbrica di pacchetti malevoli a scala industriale

Socket ha documentato che il cluster individuato in questa tornata comprende dodici pacchetti malevoli confermati e due pacchetti “dormienti”, caricati sotto alias GitHub tra cui golangorg, aokisasakidev e aokisasakidev1, con una rete di supporto operante sotto i profili maxcointech1010 e maxcointech0000.

L’elenco completo dei pacchetti identificati per ecosistema, secondo il report del ricercatore Kirill Boychenko di Socket, è il seguente: su npm i pacchetti dev-log-core, logger-base, logkitx, pino-debugger, debug-fmt e debug-glitz; su PyPI i pacchetti logutilkit, apachelicense, fluxhttp e license-utils-kit; nel registro Go i moduli github.com/golangorg/formstash e github.com/aokisasakidev/mit-license-pkg; nel registro Rust il pacchetto logtrace; nel registro PHP Packagist il pacchetto golangorg/logkit.

La scelta dei nomi non è casuale: i pacchetti erano progettati per impersonare strumenti di sviluppo legittimi come debug, debug-logfmt, pino-debug, baraka, license, http, libprettylogger e openlss/func-log, funzionando silenziosamente come malware loader. Questo schema è perfettamente coerente con quanto già documentato da ICT Security Magazine nell’analisi sulla supply chain software e i 454.000 pacchetti malevoli del 2025: la fiducia implicita nei registri pubblici è diventata l’arma più efficiente a disposizione degli attaccanti statali.

Il meccanismo di infezione: loader a due stadi invisibili al momento dell’installazione

Il malware nascosto è progettato in modo da non eseguirsi durante l’installazione del pacchetto, rendendo più difficile il rilevamento da parte degli strumenti di sicurezza tradizionali.

I loader recuperano un downloadUrl dall’infrastruttura controllata dagli attaccanti (in particolare dall’endpoint apachelicense[.]vercel[.]app), riscrivono i link di condivisione di Google Drive in formato di download diretto, scaricano archivi ZIP come ecw_update.zip e consegnano payload di secondo stadio specifici per piattaforma. Questi payload si rivelano essere malware con capacità di infostealer e remote access trojan (RAT), in grado di sottrarre credenziali, portafogli di criptovalute e garantire accesso persistente ai sistemi compromessi.

Il coordinamento cross-ecosistema è l’elemento più significativo: lo stesso cluster ha pubblicato i pacchetti su cinque registri diversi riutilizzando la stessa logica di staging, la stessa infrastruttura e gli stessi pattern di riuso delle persona. Questo indica che gli attaccanti possono continuare a portare lo stesso design di loader in nuovi registri con sole modifiche minori al codice.

Chi c’è dietro Contagious Interview: UNC1069, BlueNoroff e il link con Axios

L’attacco è attribuito a un threat actor a motivazione finanziaria noto come UNC1069, che si sovrappone ai gruppi BlueNoroff, Sapphire Sleet e Stardust Chollima. La Security Alliance (SEAL) ha dichiarato di aver bloccato 164 domini collegati a UNC1069 che impersonavano servizi come Microsoft Teams e Zoom tra il 6 febbraio e il 7 aprile 2026.

UNC1069 opera campagne di social engineering a bassa pressione e multi-settimana su Telegram, LinkedIn e Slack, impersonando contatti noti o brand credibili, o sfruttando accessi ad account aziendali e personali precedentemente compromessi, prima di consegnare un link fraudolento a una riunione Zoom o Microsoft Teams, utilizzato per veicolare lure di tipo ClickFix con conseguente esecuzione di malware su Windows, macOS e Linux.

La campagna si inserisce in un contesto più ampio di attacchi alla supply chain software da parte nordcoreana: tra le operazioni parallele figura anche l’avvelenamento del popolare pacchetto npm Axios per distribuire un impianto chiamato WAVESHAPER.V2, dopo aver preso il controllo dell’account npm del maintainer del pacchetto tramite una campagna di social engineering su misura.

Microsoft ha analizzato in dettaglio la campagna Contagious Interview, confermando come gli attori nordcoreani a motivazione finanziaria stiano evolvendo attivamente il loro toolset e la loro infrastruttura, usando domini che si spacciano per istituzioni finanziarie statunitensi e applicazioni di videoconferenza per il social engineering, con una chiara continuità nel comportamento e nell’intento.

Il modello “factory”: una minaccia sistematica e scalabile

Socket descrive Contagious Interview come una minaccia supply chain che adotta un modello a fabbrica, ben dotata di risorse, prolifica e sistematica, che tratta npm, PyPI e VS Code come canali di accesso iniziale rinnovabili verso ambienti di sviluppo e, sulla base delle indagini attuali, estende lo stesso playbook a Go Modules, crates.io e Packagist. Il totale di oltre 1.700 pacchetti malevoli tracciati è riferito all’attività complessiva della campagna a partire dal gennaio 2025.

Per comprendere la portata strutturale del problema, è utile fare riferimento all’analisi già pubblicata su ICT Security Magazine sull’avvelenamento di LiteLLM e la supply chain Python per sviluppatori AI, che descrive lo stesso schema operativo replicato da TeamPCP su cinque ecosistemi in meno di un mese. Contagious Interview applica la medesima logica su scala ancora più ampia e con risorse statali.

Le implicazioni per le organizzazioni: NIS2 e la responsabilità sulle dipendenze

La campagna Contagious Interview ha conseguenze dirette sul piano della compliance normativa. Come approfondito nell’articolo di ICT Security Magazine sugli ecosistemi digitali sotto attacco, NIS2 e gli SBOM, la NIS2 impone alle organizzazioni in scope di valutare la postura di sicurezza dei fornitori diretti e dei service provider, inclusi i componenti open source integrati nelle pipeline di sviluppo. Un pacchetto npm installato da un developer in un ambiente CI/CD è, a tutti gli effetti, un componente della supply chain soggetto a questa valutazione.

Il Cyber Resilience Act (CRA) europeo, in via di implementazione, introdurrà obblighi specifici per i produttori di software che incorporano componenti open source, rendendo la tracciabilità delle dipendenze tramite Software Bill of Materials (SBOM) non più una raccomandazione ma un requisito operativo verificabile.

Raccomandazioni operative per i team di sviluppo

Socket, che ha segnalato tutti i pacchetti malevoli identificati ai registri interessati e presentato richieste di rimozione per gli account GitHub associati, ha ottenuto la rimozione di logtrace da crates.io (con advisory tracciato come RUSTSEC-2026-0081), il blocco dei moduli Go identificati da parte del Go Security team, e la rimozione dei pacchetti aokisasakidev da npm.

Le raccomandazioni pratiche sono le seguenti: trattare come ad alto rischio i pacchetti di utilità che contattano infrastrutture remote, recuperano un downloadUrl, riscrivono link di cloud storage, scaricano archivi, decodificano contenuti remoti o avviano interpreti da funzioni helper; bloccare le versioni delle dipendenze dirette e transitive, fissando hash specifici nelle pipeline CI/CD; esaminare con attenzione i pacchetti appena pubblicati o con pochi download prima dell’adozione; eseguire i pacchetti sospetti in ambienti sandbox prima che raggiungano workstation di sviluppatori o sistemi CI; verificare i maintainer account tramite autenticazione a due fattori e monitorare i trasferimenti di ownership sui pacchetti critici.

Al momento della pubblicazione del report di Socket, alcuni pacchetti erano già stati rimossi dai registri, ma altri erano ancora attivi. Questo sottolinea la necessità di non affidarsi esclusivamente alle misure di sicurezza dei registry, ma di implementare controlli propri a livello di pipeline.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/supply-chain-attack-nordcorea/




APT28 e la campagna FrostArmada: come il GRU russo ruba credenziali Microsoft senza installare malware

Il gruppo di spionaggio russo APT28, noto anche come Fancy Bear, Forest Blizzard e Storm-2754 e riconducibile all’85° Centro Principale dei Servizi Speciali (GTsSS), Unità militare 26165 del GRU, ha condotto una campagna di cyber-spionaggio su scala globale compromettendo migliaia di router domestici e per piccoli uffici. L’operazione, denominata FrostArmada dai ricercatori di Black Lotus Labs (Lumen Technologies), ha permesso di sottrarre in modo silenzioso credenziali di accesso e token OAuth di Microsoft 365, senza che le vittime ricevessero alcun segnale di allarme tradizionale.

La campagna è stata resa pubblica il 7 aprile 2026 contestualmente all’advisory del National Cyber Security Centre (NCSC) del Regno Unito, nell’ambito di un’operazione internazionale coordinata tra autorità di law enforcement e aziende private.

Il meccanismo: DNS hijacking senza malware

La campagna su larga scala è stata denominata FrostArmada da Black Lotus Labs, con Microsoft che la descrive come uno sforzo per sfruttare dispositivi SOHO vulnerabili allo scopo di dirottare il traffico DNS e abilitare la raccolta passiva di dati di rete.

Sin dal 2024 e fino al 2026, APT28 ha configurato Virtual Private Server (VPS) per operare come server DNS malevoli. Questi VPS ricevevano volumi elevati di richieste DNS originate da router precedentemente compromessi tramite vulnerabilità note. Le impostazioni DHCP/DNS dei dispositivi venivano sovrascritte in modo da includere indirizzi IP controllati dall’attaccante, propagando le nuove configurazioni ai dispositivi della rete interna.

Quando gli utenti richiedevano i domini target, il traffico veniva reindirizzato verso un nodo adversary-in-the-middle (AitM), dove le credenziali venivano raccolte ed esfiltrate. L’unico segnale visibile per l’utente finale sarebbe stato un avviso per certificato TLS non valido.

I target del gruppo APT28 e la portata dell’operazione FrostArmada

L’attività risulta iniziata in forma limitata già a partire da maggio 2025, con una fase di compromissione su larga scala avviata da agosto. Al picco, nel dicembre 2025, oltre 18.000 indirizzi IP unici provenienti da almeno 120 paesi comunicavano con l’infrastruttura di APT28. I target primari includevano agenzie governative, ministeri degli affari esteri, forze dell’ordine e provider email e cloud di terze parti distribuiti in Africa settentrionale, America centrale, Sud-Est asiatico ed Europa.

Microsoft ha rilevato oltre 200 organizzazioni e 5.000 dispositivi consumer impattati dall’infrastruttura DNS malevola di Forest Blizzard, precisando che la telemetria non ha indicato compromissioni di asset o servizi di proprietà Microsoft.

Le operazioni di DNS hijacking sono state valutate come opportunistiche: APT28 ha preso di mira un ampio bacino di vittime, filtrando progressivamente i risultati per individuare utenti di potenziale interesse sotto il profilo dell’intelligence.

La vulnerabilità sfruttata

Uno dei modelli router sfruttati da APT28 è il TP-Link WR841N, presumibilmente attraverso la CVE-2023-50224, una vulnerabilità che consente a un attaccante non autenticato di ottenere credenziali memorizzate tramite richieste HTTP GET appositamente predisposte. Una volta ottenute le credenziali del router, l’attore inviava una seconda richiesta HTTP GET per modificare le impostazioni DNS DHCP del dispositivo, impostando il server DNS primario su un indirizzo IP malevolo e mantenendo il server secondario originale come fallback.

L’operazione di smantellamento

L’FBI ha condotto un’operazione tecnica autorizzata dall’autorità giudiziaria per mettere in sicurezza i router compromessi, rimuovendo i resolver di APT28 tramite DNS reset e ripristinando la connessione a resolver legittimi forniti dagli ISP. I comandi inviati ai router hanno anche permesso all’FBI di raccogliere prove sull’attività del gruppo. Per garantire che l’operazione non alterasse le funzionalità ordinarie dei dispositivi né raccogliesse dati degli utenti, il governo ha condotto test estensivi su firmware e hardware dei router TP-Link interessati.

Il DoJ ha precisato che gli utenti possono rimuovere eventuali modifiche residue eseguendo un ripristino alle impostazioni di fabbrica.

Il contesto geopolitico

APT28 è lo stesso gruppo responsabile della violazione del Comitato Nazionale Democratico statunitense nel 2016. L’NCSC ha precedentemente attribuito ad APT28 gli attacchi informatici al Bundestag tedesco nel 2015, che hanno incluso furto di dati e la compromissione degli account email di parlamentari e del Vice Cancelliere, nonché il tentato attacco all’Organizzazione per la Proibizione delle Armi Chimiche (OPCW) nell’aprile 2018, finalizzato a ostacolare le analisi indipendenti sulle armi chimiche impiegate dal GRU nel Regno Unito.

Le implicazioni: perché questo attacco è diverso

La campagna FrostArmada introduce un cambio di paradigma importante nella threat intelligence: il compromesso avviene a livello di infrastruttura di rete, non di endpoint. Non esiste un payload da rilevare, nessun processo anomalo da monitorare, nessun comportamento sospetto sul dispositivo dell’utente finale. L’attacco è invisibile agli strumenti EDR tradizionali e ai controlli di sicurezza perimetrali che non analizzano il traffico DNS in uscita.

Microsoft ha osservato che APT28 potrebbe sfruttare la posizione AitM acquisita per obiettivi aggiuntivi, tra cui attacchi denial of service e il deployment di malware.

Raccomandazioni operative

L’advisory NCSC fornisce indicazioni concrete per ridurre la superficie di attacco, riprese anche da Bleeping Computer con dettagli sull’operazione tecnica di smantellamento:

Sostituire i router che non ricevono più aggiornamenti di sicurezza dal produttore; mantenere il firmware sempre aggiornato all’ultima versione disponibile; non esporre le interfacce di gestione dei router su Internet; abilitare l’autenticazione a più fattori (MFA) su tutti gli account potenzialmente esposti a credential theft; monitorare le impostazioni DNS dei dispositivi di rete per rilevare modifiche non autorizzate; formare gli utenti a non ignorare gli avvisi relativi a certificati TLS non validi.

Il caso FrostArmada è un promemoria significativo del fatto che la sicurezza informatica aziendale non può prescindere dalla protezione dell’infrastruttura di rete di base, compresi i dispositivi SOHO sempre più presenti negli ambienti di lavoro ibrido e negli uffici periferici.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/apt28-frostarmada-microsoft/




LinkedIn come arma: dal phishing allo spionaggio di Stato

LinkedIn è oggi molto più di una piattaforma professionale. Per criminali comuni, gruppi APT e agenzie di intelligence straniere è diventata uno degli strumenti offensivi più versatili e difficili da contrastare nel panorama della cybersecurity. La ragione è strutturale: la piattaforma aggrega oltre un miliardo di profili autenticati, dati professionali pubblici, relazioni fiduciarie consolidate e accesso diretto a figure ad alto valore. Tutto questo avviene in un ambiente che la maggior parte delle organizzazioni non monitora con la stessa attenzione riservata alla posta elettronica.

Quello che segue è un censimento ragionato delle tecniche malevole documentate da ricercatori di sicurezza nell’ultimo anno, organizzato per livello di sofisticazione e natura dell’attore.

  1. Phishing via notifiche false: l’esca del recruiter

L’attacco più diffuso e recente è anche quello strutturalmente più insidioso nella sua semplicità. Il 31 marzo 2026, il team Cofense Phishing Defense Center ha pubblicato l’analisi di una campagna attiva in cui gli attaccanti inviano email che replicano con precisione le notifiche ufficiali di LinkedIn. Font, logo, formattazione e oggetto del messaggio sono identici agli originali. Il pretesto è una fantomatica opportunità di lavoro: un messaggio da un presunto recruiter di un’azienda reputabile, con invito urgente a rispondere.

Cliccando, l’utente non raggiunge LinkedIn, ma una pagina di login contraffatta. Il dominio impiegato nella campagna osservata era inedin[.]digital, scelto perché a una lettura rapida si confonde con il dominio legittimo. L’indirizzo email del mittente, khanieteam[.]com, è anch’esso fraudolento, attivo da pochi giorni al momento dell’analisi. I campioni osservati da Cofense erano scritti in lingua cinese e tradotti dai ricercatori.

Enrico Silverio, threat researcher al Cofense Phishing Defense Center, definisce questa campagna come «un promemoria che gli attori delle minacce continuano a evolversi in sofisticazione tecnica e persistenza, elaborando schemi altamente convincenti per sfruttare la fiducia e la curiosità umana».

L’urgenza, in questo contesto, non è un dettaglio: è la leva psicologica centrale. Silverio ricorda inoltre che gli attaccanti «pulled individuals’ home addresses, generated Google Maps screenshots, and inserted them into extortion emails to increase credibility», a conferma di quanto le campagne siano diventate personalizzate e difficili da riconoscere. Il tema dell’abuso di LinkedIn per la distribuzione di malware è approfondito nell’analisi pubblicata su ICT Security Magazine dedicata al malware veicolato tramite LinkedIn, che illustra le tecniche utilizzate dai gruppi APT per compromettere i reclutatori stessi.

  1. Phishing via commenti pubblici: la moderazione come pretesto

Una variante documentata a gennaio 2026 da Cybernews e Security Magazine sfrutta i commenti pubblici della piattaforma invece delle email. Account bot si spacciano per LinkedIn stessa, pubblicando commenti sotto i post degli utenti in cui si afferma che il profilo è stato temporaneamente ristretto per violazioni delle policy. Il messaggio invita a cliccare un link per presentare ricorso, spesso utilizzando il legittimo shortener lnkd.in di LinkedIn per mascherare la destinazione.

Chance Caldwell, Senior Director del Phishing Defense Center di Cofense, descrive questa tecnica come una «troubling evolution in social engineering tactics», in cui gli attaccanti si integrano direttamente in spazi digitali considerati affidabili e sfruttano la fiducia degli utenti mimando comunicazioni legittime. Max Gannon, Cyber Intelligence Team Manager di Cofense, sottolinea che la corretta applicazione dell’AI ha reso possibile creare a scala account che impersonano LinkedIn stesso, una soglia operativa un tempo impraticabile.

Il fattore AI è determinante: l’automazione consente di inondare le sezioni commenti a una velocità che supera ampiamente la capacità di moderazione manuale della piattaforma. LinkedIn ha confermato di essere a conoscenza della campagna, precisando che non comunica mai violazioni di policy attraverso commenti pubblici.

  1. Messaggi diretti con RAT: quando il DM diventa un vettore di intrusione

La terza tecnica è significativamente più sofisticata ed è stata documentata da ReliaQuest a gennaio 2026 in una campagna mirata a executive aziendali e amministratori IT. Il vettore non è l’email, ma il messaggio diretto su LinkedIn, a riprova che il phishing si è ormai emancipato dall’inbox.

L’attacco inizia con un DM che indirizza la vittima al download di un archivio auto-estraente WinRAR (SFX). Una volta aperto, l’archivio decomprime quattro componenti: un PDF reader legittimo open source, una DLL malevola mascherata con lo stesso nome di un file benigno usato dal PDF reader, un interprete Python portable e un file RAR utilizzato come esca per far apparire la cartella legittima. I nomi dei file sono personalizzati in base al ruolo o settore della vittima, con titoli come Upcoming_Products.pdf o Project_Execution_Plan.exe, per aumentare le probabilità che vengano aperti.

La tecnica impiegata è il DLL sideloading: il PDF reader carica automaticamente la DLL malevola al momento dell’esecuzione, eludendo l’endpoint security. Il malware installa poi una chiave Run nel registro di sistema per garantirsi persistenza a ogni avvio, esegue uno strumento di hacking open-source offuscato in Base64 direttamente in memoria (senza scrivere file su disco) e tenta ripetutamente di connettersi a un server di comando e controllo (C2). Il comportamento è compatibile con il deploy di un Remote Access Trojan per accesso persistente e furto di dati.

Come rileva The Hacker News nell’analisi della campagna, ReliaQuest sottolinea un problema strutturale: quando un account viene segnalato su LinkedIn, non è possibile vedere quali altri utenti dell’organizzazione siano stati colpiti dallo stesso messaggio. A differenza dell’email, non esiste modo di richiamare o mettere in quarantena il messaggio già inviato. Non ci sono regole modificabili né mittenti bloccabili. Si può segnalare l’account, ma probabilmente l’attaccante ha già ottenuto ciò che cercava.

  1. AiTM con redirect chain su servizi legittimi: eludere ogni filtro

La campagna più tecnicamente avanzata tra quelle di matrice criminalizzata è stata intercettata e analizzata da Push Security tra ottobre e novembre 2025. La vittima riceveva un link via DM LinkedIn relativo a una falsa opportunità di investimento: un invito a entrare nel consiglio di amministrazione di un fondo chiamato “Common Wealth”, presentato come un’iniziativa in Sud America in partnership con una fantomatica entità denominata AMCO.

Dopo aver cliccato, l’utente veniva reindirizzato tre volte (attraverso un open redirect di Google, poi a un dominio intermedio) prima di raggiungere una landing page personalizzata che imitava un portale di condivisione documenti, ospitata su firebasestorage.googleapis.com di Google. Come annunciato dalla press release ufficiale di Push Security del 30 ottobre 2025, la catena di redirect sfruttava servizi cloud legittimi (Google, Firebase, Microsoft Dynamics) per mascherare la destinazione dei link malevoli.

Gli attaccanti hanno impiegato Cloudflare Turnstile come protezione anti-bot per impedire l’analisi automatizzata delle pagine di phishing, e tecniche di offuscamento del codice per eludere i filtri basati su reputazione dei domini. La pagina finale era un sito Microsoft contraffatto di tipo AiTM (Adversary-in-the-Middle), progettato per intercettare le sessioni e bypassare l’autenticazione multifattore. Nessun gateway email, nessun URL scanner, nessuna threat intelligence feed avrebbe potuto rilevarlo: l’attacco viveva interamente nel browser dell’utente. Come riportato da BleepingComputer nella copertura originale della campagna, tra i domini malevoli impiegati figuravano boardproposalmeet[.]com e sqexclusiveboarddirect[.]icu.

  1. Lazarus Group: LinkedIn come piattaforma per finanziare il regime nordcoreano

Il livello più preoccupante di abuso di LinkedIn è quello state-sponsored. Il gruppo Lazarus, la principale unità cyber della Corea del Nord, utilizza la piattaforma come vettore primario di attacchi con obiettivi duplici: spionaggio industriale e furto di criptovalute per finanziare il programma nucleare di Pyongyang.

La campagna denominata “graphalgo”, attiva dall’inizio di maggio 2025 e analizzata da ReversingLabs nel febbraio 2026, vedeva sviluppatori avvicinati su LinkedIn, Facebook e Reddit con offerte di lavoro false nel settore blockchain e crypto, da parte di una società fittizia denominata Veltrix Capital (dominio veltrixcap[.]org, registrato ad aprile 2025). Come riportato da The Hacker News, ai candidati veniva chiesto di dimostrare le proprie competenze eseguendo un progetto che conteneva, tra le dipendenze, pacchetti malevoli pubblicati su npm e PyPI. Il pacchetto bigmathutils aveva superato le 10.000 installazioni nella versione pulita prima che venisse rilasciata la versione contenente il payload malevolo: una pazienza tattica che permette di accumulare fiducia prima di colpire.

Il malware deployato era un RAT cross-platform (in JavaScript, Python e VBScript) capace di enumerare processi, esfiltrare file, eseguire comandi arbitrari e controllare la presenza dell’estensione MetaMask nel browser per individuare wallet di criptovaluta. Parallelamente, la campagna Contagious Interview vedeva Lazarus impersonare reclutatori di aziende reali (inclusa Fireblocks stessa) per condurre finti colloqui tecnici durante i quali i candidati venivano istruiti a clonare repository GitHub e installare pacchetti npm che innescavano l’infezione.

Il CEO di Fireblocks, Michael Shaulov, che ha lavorato con LinkedIn e le forze dell’ordine per rimuovere quasi una dozzina di profili fake legati alla campagna, ha descritto l’evoluzione degli attaccanti nordcoreani a CNBC: «Nel 2017 e 2018 era relativamente facile identificarli per gli errori grammaticali. Ora sembrerebbe che si siano laureati a Oxford». L’accelerazione è attribuita direttamente all’AI: «It’s clear that the attackers have become way more sophisticated and way harder to detect because of AI».

  1. Spionaggio di Stato: la Cina e i falsi recruiter contro NATO e UE

Il 28 marzo 2026, una fonte di sicurezza europea ha confermato ad AFP quello che i servizi di intelligence occidentali sospettavano da anni: la Cina ha utilizzato profili falsi su LinkedIn per raccogliere informazioni sensibili da dipendenti di istituzioni NATO e dell’Unione Europea. L’operazione, attribuita al Ministero per la Sicurezza dello Stato cinese (MSS), ha preso di mira decine di funzionari attraverso account fittizi che si presentavano come recruiter.

Uno dei profili più attivi utilizzava il nome “Kevin Zhang”, presentandosi come responsabile di una fittizia società di Hong Kong chiamata “Oriental Consulting”. I recruiter iniziavano richiedendo report a pagamento su temi geopolitici, per poi sollecitare informazioni non pubbliche o classificate. I funzionari di Francia, Belgio e Regno Unito reclutati ricevevano compensi da poche centinaia a diverse migliaia di dollari. Gli argomenti di maggiore interesse includevano le sanzioni UE contro la Cina e la strategia NATO in Asia, in particolare riguardo a Taiwan.

La ministra belga della Giustizia Annelies Verlinden ha dichiarato ad AFP che attraverso questa operazione «a great deal of important information and intelligence may have reached China», aggiungendo che internet è diventato un terreno fertile per le grandi potenze che cercano di reclutare agenti.

Non si tratta di un caso isolato. L’utilizzo di LinkedIn da parte del MSS cinese è documentato almeno dal 2014: nel 2023, l’ex capo dell’intelligence estera francese ha rivelato che Beijing avrebbe già avviato in quell’anno un’operazione massiva di spionaggio tramite social media. Nel dicembre 2017, il BfV tedesco aveva individuato oltre 10.000 cittadini tedeschi contattati da profili falsi che prendevano di mira politici e dirigenti aziendali. A novembre 2025, MI5 ha identificato due profili LinkedIn: Amanda Qiu (BR-YR Executive Search) e Shirly Shen (Internship Union), entrambe operative del MSS impegnate a costruire relazioni con parlamentari britannici.

L’agenzia ha avvertito che i profili falsi cinesi ricorrono frequentemente all’archetipo di una giovane donna con nome anglicizzato. Le implicazioni di questa campagna per le istituzioni europee sono discusse anche nell’analisi sullo spionaggio digitale nell’era dell’intelligenza artificiale pubblicata su ICT Security Magazine, che contestualizza le operazioni del MSS nel quadro più ampio della competizione geopolitica per il controllo dell’informazione.

Il problema strutturale: un blind spot nelle difese aziendali

Distribuendo payload malevoli attraverso LinkedIn e altre piattaforme social, gli attaccanti sfruttano sistematicamente i punti ciechi nelle protezioni di cybersecurity delle organizzazioni, che spesso non coprono questi canali con la stessa attenzione riservata alla posta elettronica. Secondo Push Security, il 34% degli attacchi di phishing intercettati nell’ultimo periodo è arrivato attraverso canali non-email, tra cui social media, app di messaggistica, inserzioni pubblicitarie malevole e comunicazioni in-app. Come rilevato nel report di Push Security sul phishing 2025, LinkedIn DM e Google Search rappresentano i due canali non-email più sfruttati dagli attaccanti.

Il paradosso è che LinkedIn, proprio perché è una piattaforma percepita come affidabile e professionale, abbassa strutturalmente la soglia di guardia degli utenti. Nessuno si aspetta di essere attaccato su una piattaforma dove si gestiscono relazioni lavorative verificate. Ed è esattamente questa aspettativa che gli attaccanti, dai gruppi criminali agli APT statali, hanno imparato a monetizzare.

Raccomandazioni operative

Per i team di sicurezza aziendali, le evidenze raccolte suggeriscono di integrare nelle policy di sicurezza e nei programmi di security awareness training moduli specifici dedicati alle minacce su piattaforme social. È necessario trattare qualsiasi link o archivio ricevuto via LinkedIn DM con la stessa cautela riservata agli allegati email sospetti, non aprire mai archivi SFX o eseguibili condivisi durante processi di selezione senza verifica indipendente dell’identità del mittente, e verificare sempre l’URL del mittente nelle notifiche LinkedIn prima di cliccare. Va ricordato, infine, che LinkedIn non comunica mai restrizioni di account attraverso commenti pubblici o link in email non sollecitate.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/linkedin-cybercrime/