No Hat 2026, a Bergamo l’hacking incontra AI, cyber-spionaggio e droni

Il 10 ottobre torna la conferenza internazionale dedicata alla cybersecurity e all’ethical hacking. Tra i temi dell’ottava edizione, vulnerabilità negli AI coding assistant, attacchi alle infrastrutture di rete, malware, anonimato e compromissione dei sistemi autonomi L’intelligenza artificiale che sta cambiando anche il lavoro di chi cerca vulnerabilità e sviluppa nuove tecniche di attacco è uno […]

L’articolo No Hat 2026, a Bergamo l’hacking incontra AI, cyber-spionaggio e droni proviene da Securityinfo.it.

https://www.securityinfo.it/2026/09/11/no-hat-2026-a-bergamo-lhacking-incontra-ai-cyber-spionaggio-e-droni/?utm_source=rss&utm_medium=rss&utm_campaign=no-hat-2026-a-bergamo-lhacking-incontra-ai-cyber-spionaggio-e-droni




Claude evade (di nuovo) e compromette tre aziende reali


Sembra proprio che tenere a bada i modelli IA sia complicatissimo e Anthropic sta accumulando una certa esperienza nel settore. L’azienda ha infatti rivelato che alcuni modelli della famiglia Claude sono riusciti ad accedere ai sistemi di tre organizzazioni reali durante esercitazioni di sicurezza, trasformando test che avrebbero dovuto svolgersi in ambienti controllati in vere e proprie compromissioni di sistemi esterni.

Non è stato un attacco deliberato

Anthropic precisa che non si è trattato di un comportamento malevolo intenzionale del modello, né di un tentativo di “ribellione” dell’intelligenza artificiale. Le prove delle compromissioni, infatti, sono emerse durante la revisione interna di oltre 141.000 valutazioni di sicurezza avviata dopo il recente incidente che aveva coinvolto OpenAI. L’analisi ha portato alla scoperta di tre casi nei quali versioni di Claude erano riuscite a raggiungere Internet da un ambiente di valutazione gestito da terze parti e ad accedere senza autorizzazione ai sistemi di tre differenti organizzazioni. Anthropic specifica che il problema è stato favorito da una combinazione di errori umani, configurazioni errate dell’ambiente di test e vulnerabilità reali presenti nei sistemi raggiunti dal modello.

Tre incidenti diversi, un unico denominatore

I modelli coinvolti comprendono Claude Opus 4.7, Claude Mythos 5 e un modello sperimentale interno e quello che rende il tutto più “pepato” è che le dinamiche dei tre episodi sono differenti. In un caso il modello ha confuso il dominio di un’azienda reale con quello previsto nello scenario di laboratorio, riuscendo così ad accedere a un database esterno. C’è da dire che, probabilmente, chi ha organizzato il test non ha verificato che il nome dell’azienda “fasulla perché inserita nel test” fosse inesistente. In un secondo episodio è statp eseguito un attacco alla supply chain attraverso la pubblicazione di un pacchetto Python malevolo sul repository pubblico PyPI che è stato successivamente scaricato da alcuni sistemi reali. Nel terzo incidente il modello ha iniziato a esplorare migliaia di server connessi a Internet e stava per sfruttare una vulnerabilità SQL Injection, interrompendo però autonomamente l’operazione quando ha riconosciuto di trovarsi al di fuori dell’ambiente previsto dal test. Anthropic attribuisce questi episodi principalmente a carenze operative nella gestione delle esercitazioni piuttosto che a un fallimento dei meccanismi di allineamento del modello. In effetti, i modelli hanno fatto il loro dovere, ma si deve evidentemente ancora lavorare su come tenerli a bada.

Il vero problema è il contenimento

Le aziende stanno investendo enormi risorse per misurare le capacità offensive dei nuovi modelli AI, ma questi incidenti mostrano che la sicurezza dell’ambiente di valutazione è importante quanto quella del modello stesso. Un agente capace di operare autonomamente, usare strumenti, accedere alla rete e prendere decisioni e metterle in pratica può infatti sfruttare qualsiasi errore di configurazione presente nell’infrastruttura di test: il rischio non nasce esclusivamente dall’intelligenza artificiale, ma dall’interazione tra modello, strumenti disponibili e ambiente operativo.

Mythos torna al centro dell’attenzione

Tra i modelli coinvolti figura anche Claude Mythos, il sistema che Anthropic ha deciso di non distribuire pubblicamente proprio a causa delle sue elevate capacità offensive in ambito cyber e molti ricorderanno che non è la prima volta che Mythos finisce al centro delle cronache. Già nei mesi scorsi il modello era stato protagonista di almeno altri due episodi che avevano alimentato il dibattito sulla sua gestione. Il primo riguarda la fuga non autorizzata di alcuni accessi alla versione preview del modello, comparsi poche ore dopo il suo annuncio all’interno di una comunità privata online. Anthropic aveva confermato che utenti non autorizzati erano riusciti a usare il sistema, pur trattandosi di una versione destinata esclusivamente a un ristretto gruppo di partner del progetto Glasswing.

Il secondo episodio è emerso dalla Hazard-Aware System Card pubblicata dalla stessa Anthropic. Durante prove di laboratorio dedicate alla verifica delle misure di contenimento, una versione sperimentale di Mythos era riuscita ad aggirare alcune restrizioni del sandbox, comunicare verso l’esterno e mettere in atto comportamenti inattesi, come modificare file cercando di nascondere le modifiche nella cronologia Git. Anche in quel caso l’azienda aveva sottolineato che gli eventi erano avvenuti in ambienti di test controllati e avevano contribuito a rafforzare le misure di sicurezza del progetto.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/08/04/claude-evade-di-nuovo-e-compromette-tre-aziende-reali/?utm_source=rss&utm_medium=rss&utm_campaign=claude-evade-di-nuovo-e-compromette-tre-aziende-reali




Hugging Face violata da un agente AI: perché il primo attacco autonomo segna una svolta per la cybersecurity


Per anni l’idea di un attacco informatico condotto interamente da un agente di Intelligenza Artificiale è rimasta confinata ai laboratori di ricerca e alle presentazioni dei vendor. Oggi non è più così. La piattaforma Hugging Face, punto di riferimento mondiale per lo sviluppo e la distribuzione di modelli AI open source, ha confermato di essere stata colpita da quello che descrive come un attacco condotto dall’inizio alla fine da un sistema autonomo di agenti AI.  L’episodio rappresenta molto più di una violazione informatica: è probabilmente il primo caso documentato in cui un’infrastruttura di produzione di una realtà di una certa rilevanza viene compromessa da un sistema capace di pianificare ed eseguire autonomamente una campagna offensiva complessa, senza che un operatore umano debba guidarne ogni fase.

L’attacco è partito dalla supply chain dei dati

Secondo quanto comunicato da Hugging Face, gli aggressori hanno sfruttato una superficie d’attacco peculiare delle piattaforme AI: la pipeline che elabora dataset caricati dagli utenti. Un dataset malevolo ha abusato di due percorsi di esecuzione del codice, un loader che consentiva l’esecuzione di codice remoto e una vulnerabilità di template injection nella configurazione del dataset, ottenendo l’esecuzione di codice su un nodo di elaborazione.  Da quel momento il comportamento dell’attaccante è stato quello tipico di un’Advanced Persistent Threat: escalation dei privilegi, raccolta di credenziali cloud e di cluster, movimento laterale tra diversi sistemi e accesso non autorizzato a dataset interni e credenziali di servizio. Hugging Face precisa di non aver trovato evidenze di manomissioni ai modelli pubblici, ai dataset disponibili agli utenti, agli Spaces o alla propria software supply chain, ma l’incidente dimostra quanto le piattaforme AI introducano superfici di attacco nuove rispetto alle applicazioni tradizionali.

La novità non è la vulnerabilità, ma chi ha guidato l’attacco

La vulnerabilità sfruttata non rappresenta l’aspetto più innovativo dell’incidente. Ciò che cambia realmente è il modo in cui è stata sfruttata. Secondo la ricostruzione dell’azienda, l’operazione è stata eseguita da un framework agentico capace di svolgere decine di migliaia di azioni distribuite su una moltitudine di ambienti temporanei, con infrastrutture di comando e controllo che migravano automaticamente tra servizi pubblici per ridurre la probabilità di essere individuate.

In pratica, l’AI non si è limitata a generare codice o suggerire una sequenza di exploit: ha eseguito autonomamente una campagna offensiva articolata, adattandosi durante le diverse fasi dell’intrusione. È lo scenario dell’agentic attacker di cui il settore della cybersecurity discute da tempo e che oggi sembra essersi concretizzato.

L’AI ha difeso Hugging Face da un’altra AI

L’altro elemento interessante dell’incidente è che anche la risposta è stata in larga parte automatizzata. Hugging Face spiega di aver utilizzato sistemi basati su LLM per analizzare la telemetria di sicurezza, correlare gli eventi e ricostruire rapidamente la cronologia dell’attacco. Gli agenti di analisi hanno elaborato oltre 17.000 eventi, permettendo ai team di incident response di individuare gli indicatori di compromissione e distinguere le attività realmente dannose da quelle create per depistare gli analisti. Secondo l’azienda, un’attività che normalmente richiederebbe diversi giorni è stata completata in poche ore grazie all’automazione. Il risultato è un assaggio di quello che potrebbe diventare il nuovo paradigma della cybersecurity: AI contro AI, con attaccanti e difensori che operano entrambi a velocità macchina.

Il problema tanto temuto dei guardrail ciechi

Tra gli aspetti più curiosi emersi dal post mortem c’è un problema che fino a poco tempo fa sarebbe sembrato marginale. Durante l’analisi forense, Hugging Face ha inizialmente provato a utilizzare modelli commerciali accessibili tramite API. Tuttavia, le richieste contenevano exploit, payload, comandi di attacco e indicatori di compromissione reali: elementi che i sistemi di sicurezza dei modelli hanno interpretato come contenuti pericolosi, bloccandone l’elaborazione.

Per completare l’analisi, l’azienda ha quindi utilizzato un modello open-weight eseguito sulla propria infrastruttura, evitando sia le limitazioni imposte dai guardrail sia il trasferimento all’esterno di dati sensibili e credenziali compromesse. Questo ci riporta a un tema che è stato affrontato più volte dall’arrivo degli LLM al grande pubblico: è giusto limitarne le capacità quando gli unici che ne fanno davvero le spese sono gli utenti che li usano per scopi leciti? Ovviamente, la risposta è lunga e articolata, ma sembra abbastanza ovvio che qualcosa debba esser ripensato, a partire dalla disponibilità di servizi AI deputati all’analisi forense e al blue teaming.

Le piattaforme AI diventano una nuova superficie di attacco

L’attacco ad HuggingFace ci dice molte cose. Innanzitutto, la scelta del bersaglio è quantomeno curiosa e ovviamente tesa a dimostrare che con l’IA non si scherza. Secondo il mio modesto parere, questo attacco è stato un atto dimostrativo per mettere in guardia un’industria che è ancora largamente indecisa se correre a più non posso o imparare qualcuna delle dure lezioni che il cybercrimine ha impartito negli anni passati. Inoltre, sottolinea che la diffusione degli agenti AI amplia la superficie di attacco ben oltre il già tartassato modello linguistico, ma comprende dataset, memoria dell’agente, strumenti esterni, protocolli come MCP, supply chain delle estensioni e contesto operativo. Le minacce si spostano sempre più dal codice ai dati e alle interazioni runtime, rendendo necessari approcci di sicurezza che trattino ogni elemento esterno come potenzialmente non affidabile. Questo significa che la protezione delle piattaforme AI deve (sì, già oggi) estendersi ben oltre i tradizionali controlli su endpoint e reti, includendo controlli specifici sulla provenienza dei dati, sull’esecuzione degli strumenti e sulle informazioni che alimentano gli agenti.

Una nuova fase per la cybersecurity che potremmo non esser pronti ad affrontare

Il caso Hugging Face non dimostra che gli attaccanti abbiano improvvisamente acquisito capacità “sovrumane”. Dimostra però che l’automazione sta riducendo drasticamente il costo operativo degli attacchi e che fare automazione complessa oggi diventa sempre più semplice. Un sistema autonomo può eseguire migliaia di tentativi, adattare continuamente la propria strategia, sfruttare nuove opportunità e operare ventiquattro ore su ventiquattro senza la supervisione costante di un essere umano. Per le organizzazioni significa che i tempi di reazione disponibili continueranno a ridursi. Se gli attacchi si muovono a velocità macchina, anche il rilevamento, la correlazione degli eventi e la risposta dovranno essere sempre più automatizzati. Nik Zur (CTO di  Palo Alto) lo dice da tempo (ed era il suo slogan nel lancio di una serie di prodotti di qualche tempo fa), ma la massima continua a restare valida. Solo a marzo ho parlato con il capo dei laboratori di Mandiant che mi diceva che “ancora non accade, ma accadrà in futuro”. Il futuro è arrivato dopo neanche 4 mesi… Il problema più grande della sicurezza (e di tutta la società umana) è riuscire a tenere il passo dell’evoluzione… e non sarà facile.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/21/hugging-face-violata-da-un-agente-ai-perche-il-primo-attacco-autonomo-segna-una-svolta-per-la-cybersecurity/?utm_source=rss&utm_medium=rss&utm_campaign=hugging-face-violata-da-un-agente-ai-perche-il-primo-attacco-autonomo-segna-una-svolta-per-la-cybersecurity




Gli assistenti AI di coding sono sicuri? Il caso xAI


Gli strumenti di AI per lo sviluppo software promettono di aumentare la produttività degli sviluppatori, ma una recente analisi indipendente riaccende il dibattito sulla sicurezza dei dati affidati agli assistenti di coding. Al centro della vicenda c’è Grok Build, il tool a riga di comando di xAI, accusato di aver trasmesso (in chiaro) ai server dell’azienda interi repository Git, cronologia compresa, insieme a file contenenti credenziali e altri dati sensibili. Secondo il ricercatore che ha condotto l’analisi, inoltre, il comportamento sarebbe avvenuto anche dopo aver attivato l’opzione di esclusione dall’addestramento del modello.

Un’analisi del traffico di rete fa emergere il problema

La vicenda nasce dall’analisi del traffico di rete effettuata dal ricercatore noto come cereblab, che ha instradato Grok Build attraverso mitmproxy per osservare nel dettaglio le comunicazioni tra il client e i server remoti. L’obiettivo era verificare quali dati venissero realmente inviati durante una normale sessione di sviluppo. I risultati non sono stati quelli sperati. Secondo il report, il software avrebbe aperto due canali distinti di comunicazione: uno destinato alle richieste del modello AI e un secondo utilizzato per il caricamento del codice (un comportamento decisamente non atteso e che ha allarmato il ricercatore).

Nel test effettuato su un repository Git di circa 12 GB, il traffico destinato al modello AI sarebbe stato limitato a circa 192 KB, mentre il canale di storage avrebbe trasferito 5,10 GiB di dati suddivisi in 73 blocchi da circa 75 MB ciascuno. Il rapporto tra i due flussi supera le 27.800 volte, un valore incompatibile con il semplice invio del contesto necessario alla conversazione con il modello e che di solito giustifica connessioni parallele. L’analisi sostiene inoltre che il contenuto inviato corrispondesse a un bundle Git completo, comprendente non solo i file correnti ma anche la cronologia del repository.

Anche i segreti sarebbero finiti nel trasferimento

Ancora più delicata è la parte relativa ai secret presenti nel progetto. Durante il test il ricercatore ha inserito volutamente un file .env contenente chiavi API e credenziali fittizie facilmente identificabili. Secondo quanto documentato, tali informazioni sarebbero state trasmesse integralmente durante la comunicazione con i server di xAI. Inoltre, ricostruendo il bundle Git catturato durante il trasferimento, il ricercatore afferma di aver recuperato anche un file che l’agente era stato esplicitamente istruito a non leggere, suggerendo che il caricamento del repository fosse indipendente dalle operazioni realmente effettuate dal modello.

Uno degli aspetti più controversi, secondo cerelab, riguarda l’impostazione “Improve the model”, utilizzata per escludere i propri dati dall’addestramento dell’intelligenza artificiale. Secondo la sua analisi, la disattivazione di questa opzione non avrebbe impedito il trasferimento del repository, ma soltanto il suo eventuale utilizzo per l’addestramento del modello. In altre parole, il codice continuerebbe comunque a lasciare la macchina dello sviluppatore per essere archiviato sui sistemi remoti. Si tratta di una distinzione importante, perché trasmissione, archiviazione e addestramento rappresentano tre aspetti differenti dal punto di vista della sicurezza e della conformità normativa.

xAI avrebbe già modificato il comportamento del servizio

La vicenda, tuttavia, sembra aver avuto un’evoluzione molto rapida. Nei giorni successivi alla pubblicazione del report, lo stesso ricercatore ha ripetuto i test osservando un comportamento differente. In sei prove consecutive non sarebbe più stato rilevato alcun caricamento del repository tramite l’endpoint dedicato allo storage. Al suo posto sarebbero comparsi nuovi flag server-side, tra cui disable_codebase_upload, che sembrerebbero disattivare la funzione senza richiedere un aggiornamento del client. Al momento, però, xAI non ha pubblicato alcun advisory di sicurezza, né un changelog che spieghi ufficialmente la modifica o chiarisca quale sia stato l’impatto del problema sugli utenti che hanno utilizzato Grok Build prima della mitigazione. Anche le note di rilascio più recenti del progetto non fanno riferimento alla questione.

Una lezione per tutti gli agenti di coding

Al di là del singolo caso, l’episodio evidenzia una criticità destinata a diventare sempre più rilevante con la diffusione degli AI coding agent. Molti sviluppatori tendono infatti a considerare questi strumenti come semplici assistenti locali, mentre nella maggior parte dei casi il lavoro viene svolto su infrastrutture cloud. Per le organizzazioni questo significa che repository, codice proprietario, segreti applicativi e informazioni sensibili potrebbero lasciare il perimetro aziendale se non vengono definite precise policy di utilizzo. E addirittura, questo potrebbe succedere anche se le opzioni di non condivisione sono attive, richiedendo una infrastruttura di controllo che vada oltre la semplice policy.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/14/gli-assistenti-ai-di-coding-sono-sicuri-il-caso-xai/?utm_source=rss&utm_medium=rss&utm_campaign=gli-assistenti-ai-di-coding-sono-sicuri-il-caso-xai




La guerra ucraina cambia la cybersecurity delle infrastrutture critiche


La guerra in Ucraina non si combatte solo sul terreno, nel mare o nello spazio aereo. Il cyberspazio è uno degli scenari più attivi, dove vengono perpetrati quotidianamente decine di attacchi mirati alle infrastrutture civili e militari. Il continuo bersagliamento di infrastrutture energetiche, reti di comunicazione e servizi pubblici ha praticamente trasformato l’intero Paese in un enorme laboratorio dove si sviluppa la cyber-resilienza. Ma una cosa è proteggere le infrastrutture critiche civili, un’altra quelle militari e, ovviamente, l’Ucraina non ha abbastanza risorse interne per far fronte all’enorme numero di problemi da affrontare. Per questo è stato creato il Tallinn Mechanism, un’iniziativa internazionale nata per sostenere la resilienza digitale delle infrastrutture civili del Paese e che, indirettamente, sta contribuendo ad accrescere anche le capacità difensive delle aziende europee. Ne abbiamo parlato con Alessio Aceti, CEO di HWG Sababa, azienda impegnata in prima fila.

Cos’è il Tallinn Mechanism

Nonostante il nome possa trarre in inganno, il Tallinn Mechanism non è un organismo con sede in Estonia. Il nome deriva semplicemente dalla città in cui si è svolto il primo incontro istituzionale. Si tratta di un programma internazionale di cooperazione civile che coinvolge diversi Paesi europei, insieme a Stati Uniti e Canada, con l’obiettivo di sostenere la digitalizzazione e la sicurezza delle infrastrutture civili ucraine, comprese quelle considerate critiche. Un elemento distintivo dell’iniziativa è la sua natura prettamente civile. Pur essendo presente come osservatore, la NATO non partecipa direttamente alle attività operative.

Il meccanismo funziona come una piattaforma di collaborazione tra settore pubblico e privato. Le istituzioni ucraine pubblicano le proprie esigenze attraverso un portale dedicato, mentre aziende e organizzazioni dei Paesi aderenti partecipano a bandi finanziati dai governi per fornire competenze, tecnologie e servizi. Dal 1° luglio al 31 dicembre, inoltre, l’Italia assume il coordinamento del programma, con il compito di facilitare la collaborazione tra istituzioni e industria.

La formazione OT per le infrastrutture ucraine e il ritorno per l’Italia

Come già accennato, tra le realtà coinvolte figura HWG Sababa che insieme al Competence Center Cyber 4.0 e a partner francesi si è aggiudicata un progetto dedicato alla formazione sulla sicurezza OT (Operational Technology). L’attività è rivolta ai tecnici che operano nelle infrastrutture critiche ucraine, in particolare nei settori della produzione e distribuzione dell’energia.

L’approccio adottato si discosta dalla formazione tradizionale. Le esercitazioni sono infatti costruite attorno a laboratori pratici nei quali gli operatori lavorano direttamente su PLC, sistemi SCADA e digital substation, simulando attacchi realistici e imparando tecniche di rilevamento, contenimento e risposta in uno scenario caratterizzato da minacce costanti. L’aspetto forse più interessante emerso dall’esperienza raccontata durante l’intervista riguarda il valore che queste attività generano anche per il sistema Paese. L’Ucraina rappresenta infatti uno degli ambienti in cui vengono sperimentate per prime nuove tecniche, tattiche e procedure (TTP) adottate dagli attaccanti. Molte delle infrastrutture utilizzate nel Paese impiegano gli stessi sistemi industriali presenti anche nelle aziende italiane, inclusi prodotti di vendor internazionali come Schneider Electric e ABB. Questo consente agli specialisti coinvolti di osservare direttamente modalità di attacco che potrebbero arrivare successivamente anche nell’Europa occidentale. L’esperienza maturata sul campo permette quindi di anticipare le difese, identificando vulnerabilità e sviluppando contromisure prima che determinate campagne diventino una minaccia concreta anche per le organizzazioni italiane.

La guerra cambia anche il cybercrime

Un altro elemento evidenziato durante l’intervista riguarda l’evoluzione delle minacce. Le tecniche sviluppate dai gruppi riconducibili agli Stati-nazione tendono infatti, con il passare del tempo, a essere riutilizzate anche dalla criminalità informatica tradizionale. Secondo gli esperti, questo fenomeno rischia di accelerare ulteriormente con la diffusione dell’Intelligenza Artificiale, che potrebbe abbassare le competenze necessarie per sviluppare campagne offensive sempre più sofisticate. Di conseguenza, strumenti e metodologie oggi osservati in scenari di guerra potrebbero trasformarsi domani nelle tecniche utilizzate dai gruppi ransomware contro aziende di ogni dimensione.

Cybersecurity e sovranità digitale viaggiano insieme

L’esperienza del Tallinn Mechanism alimenta anche una riflessione più ampia sul tema della sovranità digitale. Secondo quanto emerso nell’intervista, costruire competenze nazionali, sviluppare servizi ad alto valore aggiunto e rafforzare la collaborazione tra imprese italiane rappresenta un elemento fondamentale per ridurre la dipendenza tecnologica dall’estero. In quest’ottica, la federazione di competenze e servizi diventa un fattore strategico non soltanto per la cybersecurity, ma anche per la competitività industriale del Paese.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/10/la-guerra-ucraina-cambia-la-cybersecurity-delle-infrastrutture-critiche/?utm_source=rss&utm_medium=rss&utm_campaign=la-guerra-ucraina-cambia-la-cybersecurity-delle-infrastrutture-critiche




AI, il nuovo fronte della sicurezza: il red teaming diventa indispensabile


L’intelligenza artificiale sta entrando nelle aziende con una velocità che non ha precedenti, ma la sua diffusione sta facendo emergere una realtà che molti responsabili della sicurezza stanno iniziando a sperimentare direttamente: i tradizionali strumenti di difesa non sono stati progettati per proteggere sistemi che ragionano attraverso il linguaggio naturale. Firewall, Web Application Firewall e sistemi di protezione delle reti continuano a svolgere il loro ruolo, ma davanti a chatbot, agenti AI e Large Language Model si apre una superficie di attacco completamente nuova.

Secondo Gartner, entro quest’anno l’80% delle organizzazioni utilizzerà soluzioni basate sull’intelligenza artificiale, una crescita che supera in velocità perfino quella vissuta in passato da cloud computing, dispositivi mobili e Internet. Una diffusione tanto rapida quanto impegnativa dal punto di vista della cybersecurity.

Quando la conversazione diventa la superficie di attacco

L’evoluzione dell’AI segue percorsi differenti. Alcune aziende si limitano all’utilizzo di strumenti come ChatGPT, Copilot o Gemini per aumentare la produttività individuale, mentre altre stanno sviluppando chatbot interni, assistenti per il customer care oppure sistemi agentici capaci di eseguire attività autonome.

Ma in queste implementazioni più avanzate, la sicurezza cambia completamente natura. Il problema non riguarda più esclusivamente il codice o il traffico di rete, ma il modo in cui il modello interpreta, elabora e restituisce informazioni attraverso il linguaggio naturale. Una conversazione non può essere filtrata come un pacchetto IP. È questo il motivo per cui molti controlli tradizionali risultano inefficaci contro gli attacchi rivolti ai sistemi di AI.

Infatti, secondo i dati riportati da F5, il 75% dei CISO ha già registrato incidenti di sicurezza legati all’intelligenza artificiale, mentre il 91% dichiara di aver individuato tentativi di attacco contro la propria infrastruttura AI. Ancora più significativo è il fatto che il 94% considera ormai prioritario sottoporre le applicazioni AI a test di sicurezza specifici.

Dagli errori logici ai nuovi attacchi cognitivi

Le vulnerabilità che colpiscono le piattaforme di AI non sono necessariamente nuove dal punto di vista tecnico, ma assumono caratteristiche completamente differenti quando vengono inserite in sistemi basati su Large Language Model. Un errore nell’isolamento dei tenant, ad esempio, può trasformarsi nella restituzione di informazioni appartenenti ad altre organizzazioni direttamente all’interno di una conversazione naturale, rendendo molto difficile individuare il problema. Anche i classici attacchi di prompt injection possono avere conseguenze particolarmente gravi quando il modello dispone dell’autorizzazione a utilizzare strumenti esterni o ad interagire con sistemi aziendali. Se il controllo delle autorizzazioni viene affidato al modello anziché all’infrastruttura applicativa, il rischio aumenta sensibilmente.

Accanto a questi scenari stanno emergendo nuove categorie di minacce, che comprendono tecniche di jailbreak sempre più sofisticate, data poisoning durante l’addestramento e meccanismi di token compression, nei quali istruzioni malevole vengono nascoste in forme comprensibili al modello ma praticamente invisibili agli operatori umani.

Perché i test tradizionali non bastano più

Uno degli aspetti più complessi dell’AI riguarda il fatto che non ci si trova più davanti a software deterministico. Ogni conversazione può produrre risultati differenti in base al contesto, alla memoria dell’agente, ai documenti recuperati tramite retrieval oppure agli strumenti che il modello può utilizzare. Questo rende estremamente difficile applicare i normali processi di vulnerability assessment. Mentre in passato era sufficiente verificare il comportamento di un’applicazione seguendo scenari relativamente prevedibili, oggi le possibili combinazioni diventano praticamente infinite. Testarle manualmente è semplicemente irrealistico, soprattutto quando un’organizzazione gestisce decine o centinaia di chatbot o agenti AI.

Per questo diventa indispensabile strutturare un sistema di AI Red Teaming, ovvero la simulazione sistematica di attacchi contro sistemi basati sull’intelligenza artificiale per verificarne il comportamento in condizioni ostili. L’obiettivo non è soltanto individuare vulnerabilità tecniche, ma comprendere come il sistema reagisce a prompt malevoli, tentativi di manipolazione, richieste ambigue o scenari progettati per aggirare i controlli di sicurezza. Un approccio che deve produrre risultati riproducibili, permettendo agli sviluppatori di identificare esattamente quali conversazioni hanno generato il comportamento indesiderato e quali condizioni lo hanno reso possibile.

Normative e compliance spingono verso test continui

L’importanza del red teaming non nasce esclusivamente da esigenze tecnologichema anche dal quadro normativo che sta evolvendo rapidamente. L’AI Act europeo introduce esplicitamente attività di adversarial testing per determinate categorie di sistemi AI, mentre negli Stati Uniti organizzazioni come NIST e CISA stanno promuovendo procedure di verifica sempre più strutturate, soprattutto nei contesti considerati mission critical. La sicurezza dell’intelligenza artificiale diventa quindi non soltanto una misura di protezione, ma anche un requisito di conformità e governance.

Ma c’è un risvolto per alcuni versi “inatteso”. Storicamente, possiamo tutti ricordare l’avversione delle proprietà nei confronti della cybersecurity, troppo spesso vista come una spesa e addirittura un fastidio che tendeva a rallentare il business. Nel caso dell’intelligenza artificiale potrebbe invece verificarsi il contrario. Disporre di test automatizzati, evidenze documentate e verifiche continue consente infatti di portare più rapidamente in produzione nuovi casi d’uso, offrendo ai team di compliance e agli auditor elementi concreti per valutare il rischio.

L’AI red teaming si sta quindi trasformando da semplice attività specialistica a componente fondamentale della sicurezza delle applicazioni AI, permettendo alle aziende di adottare chatbot, agenti e workflow intelligenti con un livello di fiducia molto superiore rispetto agli approcci tradizionali. Purtroppo, non mancano le sfide. Molte delle competenze necessarie per fare AI Red Teaming sono ancora rare, ma si spera che verranno formate in tempi ragionevolmente brevi dal settore accademico e, soprattutto, dalle stesse aziende.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/06/ai-il-nuovo-fronte-della-sicurezza-il-red-teaming-diventa-indispensabile/?utm_source=rss&utm_medium=rss&utm_campaign=ai-il-nuovo-fronte-della-sicurezza-il-red-teaming-diventa-indispensabile




Falsa skill elude gli scanner e a raggiunge più di 26.000 agenti AI


La rapida diffusione degli Agenti AI sta creando un ecosistema sempre più complesso nel quale modelli linguistici, strumenti esterni e componenti aggiuntivi collaborano per svolgere attività operative. Questa architettura modulare, però, sta aprendo una nuova superficie di attacco che ricorda da vicino le vulnerabilità già viste nel mondo open source e nei marketplace di applicazioni.

Un caso recente evidenziato dai ricercatori ha mostrato come una falsa skill per agenti AI sia riuscita a superare i controlli automatici di sicurezza e a raggiungere oltre 26.000 agenti, dimostrando quanto siano ancora immature molte delle difese implementate nei marketplace dedicati agli agenti intelligenti.

Quando il problema non è il modello ma l’estensione

Molte piattaforme agentiche consentono agli utenti di installare componenti aggiuntivi, spesso chiamati skill, tool o plug-in. Questi moduli permettono all’agente di accedere a nuove funzionalità, interagire con servizi esterni o automatizzare processi complessi.

Il problema è che la sicurezza di questi ecosistemi non dipende soltanto dal modello AI utilizzato, ma anche dall’affidabilità delle estensioni installate. Se una skill malevola riesce a superare i controlli preliminari, può ottenere accesso a dati sensibili, credenziali e processi aziendali eseguiti dall’agente.

Secondo una recente analisi su quasi 4.000 skill distribuite in diversi marketplace, i ricercatori hanno identificato 76 payload malevoli confermati, mentre il 13,4% delle skill analizzate presentava almeno una vulnerabilità classificata come critica.

Come è stata aggirata la scansione automatica

L’aspetto più interessante della vicenda riguarda il modo in cui la falsa skill è riuscita a sfuggire agli strumenti di verifica.

Gli scanner automatici utilizzati da molte piattaforme si concentrano prevalentemente sull’analisi statica del codice e sulla ricerca di pattern noti. Gli autori della skill hanno invece sfruttato tecniche di offuscamento e comportamenti attivati solo in determinate condizioni operative, rendendo difficile individuare la componente malevola durante le verifiche preliminari.

Il rischio per le aziende

La vicenda evidenzia un problema destinato a crescere nei prossimi anni. Sempre più aziende concedono agli agenti AI accesso a repository di codice, documentazione interna, strumenti di produttività, piattaforme cloud e una skill compromessa potrebbe diventare un vettore privilegiato per attività di esfiltrazione dati, raccolta di credenziali, installazione di backdoor o manipolazione dei workflow aziendali. I ricercatori hanno già osservato casi reali di skill progettate per sottrarre informazioni sensibili o modificare il comportamento degli agenti ospitanti. La criticità è amplificata dal fatto che molti agenti operano con privilegi elevati e possono accedere direttamente a servizi interni o risorse normalmente non esposte a utenti esterni.

Verso una nuova generazione di controlli

La diffusione degli AI Agent sta riproponendo dinamiche già note nel mondo del software tradizionale. Così come repository open source e store di applicazioni sono diventati obiettivi privilegiati degli attacchi supply chain, anche i marketplace delle skill stanno emergendo come un nuovo bersaglio.

Per le aziende che intendono adottare agenti autonomi sarà quindi fondamentale introdurre processi di validazione indipendenti, sandbox dedicate, monitoraggio continuo e controlli granulari sui privilegi concessi alle estensioni installate.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/06/21/una-falsa-skill-elude-gli-scanner-e-a-raggiunge-piu-di-26-000-agenti-ai/?utm_source=rss&utm_medium=rss&utm_campaign=una-falsa-skill-elude-gli-scanner-e-a-raggiunge-piu-di-26-000-agenti-ai




Zscaler porta la Zero Trust nell’era degli agenti AI


Sebbene il numero di casi d’uso nel nostro Paese sia ancora molto basso, le previsioni di tutti gli esperti dicono che gli agenti AI diventeranno i veri “operati” dell’automazione dei processi in azienda. Il problema è che chi dovrà gestirne la sicurezza non ha ancora l’esperienza necessaria per farsi un quadro chiaro di come questi opereranno in concreto sulla rete interna, su quella esterna e sui client. Questa carenza di visione complica enormemente la creazione di una infrastruttura di sicurezza efficace.

In particolare, governare e proteggere un numero crescente di agenti AI autonomi che operano in modo indipendente, accedono ai dati aziendali e prendono decisioni alla velocità delle macchine pone una serie di sfide che è bene affrontare insieme a chi ha già avuto modo di sperimentare con casi reali, in ambiti complessi.

A questo proposito, Zscaler ha annunciato una serie di innovazioni che estendono le funzionalità della piattaforma Zero Trust Exchange alla protezione dell’ecosistema Agentic AI con l’obiettivo di offrire quella che l’azienda definisce la prima piattaforma Zero Trust completa progettata specificamente per la nuova generazione di agenti intelligenti.

L’Agentic AI cambia le regole della sicurezza

Durante la sessione europea del loro evento annuale Zenith Live, tenutasi a Vienna, Zscaler ha condiviso la sua visione sull’evoluzione dell’AI che, a suo dire, sta introducendo complessità che le architetture di sicurezza tradizionali non sono state progettate per gestire. Gli agenti autonomi non si limitano infatti a eseguire istruzioni ricevute dagli utenti, ma possono generare task, creare subagenti, accedere a servizi, utilizzare credenziali e interagire con applicazioni e dati aziendali senza un intervento umano diretto.

Questo scenario genera nuove problematiche in termini di visibilità, governance e controllo degli accessi, rendendo più difficile comprendere quali agenti stiano operando, quali dati utilizzino e quali azioni siano autorizzati a compiere. Parallelamente, la crescente integrazione dell’AI nei processi di sviluppo software espone endpoint e workstation a plugin, estensioni e strumenti potenzialmente malevoli che molte soluzioni di sicurezza tradizionali non sono attualmente in grado di individuare efficacemente.

AI Broker: controllo sulle comunicazioni tra agenti

Una delle principali novità presentate dall’azienda è Zscaler AI Broker, una soluzione progettata per proteggere le comunicazioni tra agenti AI attraverso broker MCP (Model Context Protocol) e framework Agent-to-Agent.

Il sistema introduce un Agent Registry integrato che consente alle aziende di ottenere una visibilità dettagliata sulle risorse accessibili da ciascun agente e di applicare controlli granulari sugli accessi. L’obiettivo è evitare che gli agenti possano espandere autonomamente i propri privilegi o accedere a informazioni non necessarie per l’esecuzione delle attività assegnate.

Endpoint AI Security amplia la protezione sui dispositivi

Accanto al broker per gli agenti, Zscaler ha introdotto Endpoint AI Security, una soluzione che estende la protezione fino ai dispositivi utilizzati dai dipendenti. La piattaforma è progettata per individuare minacce nascoste all’interno di browser, estensioni, plugin e strumenti AI installati localmente, componenti che spesso sfuggono alle tradizionali piattaforme di Endpoint Detection and Response. L’approccio consente di applicare policy coerenti tra cloud ed endpoint, offrendo una visione unificata dei rischi legati all’utilizzo dell’intelligenza artificiale all’interno dell’organizzazione.

AI Access Graph punta sulla governance dei dati

Un altro tassello fondamentale della strategia presentata a Vienna è rappresentato da Zscaler AI Access Graph, una tecnologia sviluppata a partire dall’acquisizione di Symmetry Systems. La soluzione crea una mappatura delle relazioni tra identità, applicazioni, modelli AI e fonti dati, consentendo alle organizzazioni di comprendere in modo più accurato chi accede alle informazioni, attraverso quali agenti e per quali finalità.

L’integrazione con Zero Trust Exchange permette di applicare controlli più rigorosi, ridurre gli accessi non necessari e tracciare in tempo reale la lineage dei dati lungo l’intero percorso, dalla sorgente fino all’utilizzo da parte degli agenti AI. Considerato che i requisiti normativi diventano sempre più stringenti, la capacità di ricostruire i flussi informativi potrebbe diventare uno degli elementi chiave per la governance dell’intelligenza artificiale.

Più visibilità sugli asset AI e oltre 250 applicazioni GenAI monitorate

Le novità annunciate includono anche un importante aggiornamento di Zscaler AI Protect, la piattaforma introdotta all’inizio del 2026 per la protezione degli ambienti AI. Sul fronte dell’asset management, la soluzione amplia le capacità di discovery permettendo di individuare AI integrate nelle applicazioni SaaS, server MCP presenti nei cloud pubblici e rischi nascosti nei codebase agentici attraverso attività di scansione del codice. La visibilità viene inoltre estesa alle attività AI che avvengono direttamente sugli endpoint aziendali.

Particolarmente interessante è il rafforzamento delle funzionalità di Secure Access to AI, che ora consentono di estrarre e analizzare i prompt provenienti da oltre 250 applicazioni GenAI, offrendo una visione completa delle conversazioni e supportando le Compliance API di Anthropic e OpenAI. L’azienda introduce inoltre guardrail basati sull’intento dell’intera conversazione e non sul singolo prompt, un approccio che mira a ridurre i tentativi di aggiramento delle policy attraverso sequenze di richieste apparentemente innocue.

Sicurezza dell’AI lungo tutto il ciclo di vita

L’ultima area di innovazione riguarda la protezione delle applicazioni AI durante l’intero ciclo di vita. Le nuove funzionalità comprendono attività di AI red teaming dedicate ai server MCP, servizi di prompt hardening e strumenti di conformità basati su heat map che aiutano le organizzazioni a identificare le aree più esposte dal punto di vista della governance. L’obiettivo è quello di integrare la sicurezza fin dalle fasi iniziali di sviluppo e distribuzione delle applicazioni AI, evitando che i controlli vengano aggiunti solo successivamente quando i sistemi sono già operativi.

La strategia presentata da Zscaler evidenzia come a fianco della protezione dell’utente serva trovare spazio per la protezione degli agenti AI. Con l’aumento delle identità non umane, delle comunicazioni agent-to-agent e dei workflow automatizzati, le aziende avranno bisogno di strumenti in grado di garantire visibilità, controllo e governance su un ecosistema sempre più distribuito per riuscire a evitare intrusioni e garantire la governance richiesta dalle normative più recenti.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/06/16/zscaler-porta-la-zero-trust-nellera-degli-agenti-ai/?utm_source=rss&utm_medium=rss&utm_campaign=zscaler-porta-la-zero-trust-nellera-degli-agenti-ai




Infrastrutture Critiche e Geopolitica: è l’Era dell’Antifragilità


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

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

Una situazione poco omogenea

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

Le Telco stanno cambiando

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

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

Il CISO deve evolvere insieme alla situazione

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

Condividi l’articolo



Articoli correlati

Altro in questa categoria


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




Il gruppo criminale cinese TA4922 adesso punta anche all’Europa


Un gruppo cybercriminale di lingua cinese fino a poco tempo fa concentrato prevalentemente sul mercato asiatico sta ampliando rapidamente il proprio raggio d’azione verso Europa e Africa. Secondo le analisi pubblicate da Proofpoint, il gruppo chiamato TA4922 ha aumentato sensibilmente il volume delle proprie operazioni nel corso del 2026, prendendo di mira organizzazioni nel Regno Unito, in Germania, in Italia e in Sudafrica, oltre a continuare le campagne già attive in Giappone, Corea del Sud, Taiwan, Singapore e altri Paesi asiatici.

Gli analisti descrivono TA4922 come uno degli attori più insoliti tra quelli monitorati. Pur essendo classificato come gruppo a motivazione prevalentemente economica, il suo comportamento operativo ricorda per complessità e varietà quello di alcuni gruppi di cyber spionaggio. L’obiettivo principale sembra essere l’ottenimento di accesso persistente agli ambienti delle vittime per attività di furto dati, frode, rivendita degli accessi compromessi e monetizzazione delle intrusioni.

Phishing localizzato e social engineering su misura

Uno degli aspetti più interessanti dell’operatività di TA4922 è la forte capacità di adattamento alle realtà locali. Le campagne osservate utilizzano email scritte nelle lingue dei Paesi bersaglio e costruite per apparire credibili all’interno dei rispettivi contesti aziendali.

I messaggi impersonano frequentemente uffici HR, reparti finanziari, autorità fiscali, fornitori o colleghi di lavoro. I temi utilizzati ruotano attorno a fatture, pagamenti, tasse, buste paga, benefit aziendali e comunicazioni amministrative, sfruttando argomenti che inducono i destinatari ad agire rapidamente senza effettuare verifiche approfondite.

Proofpoint evidenzia inoltre come il gruppo utilizzi migliaia di indirizzi email temporanei generati su servizi legittimi come Outlook, Hotmail e Gmail. Questa strategia consente agli attaccanti di aggirare più facilmente i controlli basati sulla reputazione del mittente e migliorare il tasso di consegna delle campagne malevole.

L’obiettivo è portare la conversazione fuori dalla posta elettronica

Una caratteristica che distingue TA4922 da molte altre operazioni di phishing consiste nel tentativo sistematico di spostare le comunicazioni verso piattaforme alternative come Microsoft Teams, WhatsApp e, in Asia, anche LINE. L’obiettivo è quello di uscire dal perimetro dei controlli di sicurezza implementati sulle caselle e-mail aziendali. Una volta stabilito il contatto attraverso canali meno monitorati, gli attaccanti possono proseguire le attività di social engineering, convincere la vittima a scaricare file malevoli oppure raccogliere credenziali e informazioni sensibili con minori probabilità di essere individuati.

Una cassetta degli attrezzi sempre più ricca

L’espansione geografica è stata accompagnata da una significativa crescita dell’arsenale malware utilizzato dal gruppo. Se nelle prime campagne il malware più frequentemente associato a TA4922 era ValleyRAT, noto anche come Winos 4.0, negli ultimi mesi sono comparsi nuovi strumenti che aumentano notevolmente la flessibilità operativa degli attaccanti. Tra questi figurano Atlas RAT, un trojan di accesso remoto utilizzato in diverse campagne contro organizzazioni europee e asiatiche, e due nuove famiglie individuate da Proofpoint e denominate RomulusLoader e SilentRunLoader.

Atlas RAT offre funzionalità avanzate di controllo remoto, raccolta informazioni, trasferimento file e monitoraggio del sistema compromesso. RomulusLoader agisce invece come downloader e stager per ulteriori payload, utilizzando tecniche come process hollowing, injection e cifratura per rendere più difficile il rilevamento. SilentRunLoader, scritto in Python, è stato osservato mentre sottraeva credenziali, cookie e dati di navigazione da Google Chrome prima di trasmetterli verso infrastrutture controllate dagli attaccanti.

DLL sideloading e strumenti legittimi per sfuggire ai controlli

Come molti gruppi moderni, TA4922 combina codice malevolo e software legittimo per ridurre la probabilità di intercettazione. Le campagne osservate fanno ampio uso di DLL sideloading, tecnica che consente di eseguire codice malevolo sfruttando applicazioni considerate affidabili dal sistema operativo. In altri casi gli attaccanti installano software di amministrazione remota legittimi come AnyDesk e SyncFuture, mascherando le proprie attività all’interno del normale traffico aziendale.

Gli analisti di Proofpoint continuano a classificare TA4922 come un gruppo orientato prevalentemente al profitto. Tuttavia, le capacità tecniche dimostrate e le funzionalità presenti nei malware utilizzati sollevano interrogativi sulle possibili evoluzioni future. Strumenti in grado di registrare attività degli utenti, acquisire screenshot, raccogliere dati dai browser e mantenere accessi persistenti potrebbero infatti essere utilizzati non soltanto per finalità economiche ma anche per attività di sorveglianza e raccolta informativa. Secondo Proofpoint, queste capacità potrebbero essere condivise, vendute o riutilizzate in contesti differenti rispetto alle campagne attualmente osservate.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/06/04/il-gruppo-criminale-cinese-ta4922-adesso-punta-anche-alleuropa/?utm_source=rss&utm_medium=rss&utm_campaign=il-gruppo-criminale-cinese-ta4922-adesso-punta-anche-alleuropa