Mag 28, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenario, Scenario 0

---

A leggere il nuovo “2026 Cloud Security Report” realizzato da Check Point insieme a Cybersecurity Insiders, sembra proprio che l’adozione dell’intelligenza artificiale nelle aziende stia crescendo più rapidamente della capacità delle organizzazioni di proteggerla.

Il report, basato sulle risposte di 1.042 professionisti IT e cybersecurity provenienti da organizzazioni di tutto il mondo, mostra un quadro chiaro, preoccupante, ma anche atteso dal momento che ogni grande innovazione che porta “urgenza” tende a far prevalere la necessità di implementazione su quella della sicurezza “by design”. Così l’AI è già entrata nei processi produttivi, ma le architetture di sicurezza non sono state progettate per gestire traffico AI-driven, agenti autonomi e modelli generativi operativi su larga scala.

L’AI è già in produzione, ma la sicurezza è rimasta indietro

Il dato forse più importante dell’intero report riguarda la velocità dell’adozione. Il 70% delle organizzazioni dichiara infatti di avere già workload GenAI in produzione, mentre il 64% ha implementato agenti AI in ambienti pilota o direttamente in sistemi live. Ancora più significativo è il fatto che il 12% delle aziende abbia già concesso agli agenti AI accessi privilegiati a sistemi core aziendali.

Purtroppo, come dicevamo, sembra che le infrastrutture di difesa non stiano tenendo il passo. L’83% delle organizzazioni ritiene infatti che proteggere sistemi GenAI sia più difficile rispetto alle applicazioni tradizionali. La difficoltà nasce dal fatto che le architetture di sicurezza storiche erano state progettate per utenti umani, SaaS relativamente prevedibili e flussi applicativi stabili, non per agenti autonomi, API dinamiche e traffico AI machine-to-machine.

Il 78% delle aziende ha già visto incidenti AI-related o teme di averli subiti

Il 54% delle organizzazioni conferma di avere già subito almeno un incidente di sicurezza collegato all’AI, mentre un ulteriore 24% sospetta incidenti ma ammette di non avere sufficiente telemetria per verificarli. Complessivamente, il 78% delle aziende ha già registrato o teme di avere registrato impatti legati all’intelligenza artificiale.

Fra gli incidenti più frequenti emergono l’utilizzo non autorizzato di strumenti AI (“shadow AI”), segnalato dal 41% delle organizzazioni, l’impiego di contenuti generati dall’AI in attacchi phishing o deepfake, indicato dal 37%, e la perdita di dati sensibili attraverso servizi AI, fenomeno che riguarda il 32% delle aziende intervistate.

Secondo il report, uno dei problemi principali è che il traffico AI assomiglia spesso a traffico legittimo. Chiamate API verso LLM, richieste outbound e comunicazioni agent-to-agent possono facilmente mimetizzarsi nel traffico normale se i sistemi di ispezione non sono progettati specificamente per interpretare il contesto AI.

Il gap più grave: strategia e architettura non coincidono

Uno degli elementi più impressionanti dello studio è il cosiddetto “AI readiness gap”. Il 77% delle organizzazioni afferma di avere modificato la propria strategia di sicurezza in risposta all’AI, ma solo il 26% ritiene che la propria architettura sia effettivamente pronta a supportare workload AI senza importanti redesign infrastrutturali. Il risultato è un divario di 51 punti percentuali tra strategia e capacità reale di enforcement. In pratica, le aziende stanno aggiornando policy, governance e budget, ma i controlli non riescono ancora a propagarsi in modo coerente tra cloud, SaaS, data center, endpoint e workload AI.

Secondo Check Point, questo scenario sta creando policy frammentate, punti ciechi e perdita di controllo sui flussi AI distribuiti nell’ambiente ibrido enterprise.

Le aziende non vedono davvero l’AI che usano

La mancanza di visibilità è un altro tema centrale. Solo il 5% delle organizzazioni dichiara di avere piena visibilità sugli strumenti AI utilizzati dai dipendenti. Questo significa che il restante 95% prende decisioni di governance senza sapere davvero quali modelli, servizi, agenti o workflow AI siano attivi nell’organizzazione. Ancora più preoccupante è il fatto che solo il 5% affermi di riuscire a distinguere in modo affidabile attività AI legittime da utilizzi sospetti o non autorizzati. Gli strumenti tradizionali di discovery, sottolinea il report, erano stati progettati per individuare SaaS catalogati e applicazioni note, non chiamate API verso LLM, notebook AI o agenti che utilizzano account di servizio già esistenti.

Il traffico AI sta mettendo in crisi le infrastrutture di rete

L’intelligenza artificiale sta modificando rapidamente i pattern di traffico nelle reti enterprise. Il 51% delle aziende segnala un aumento del traffico API-driven, il 48% vede crescere il traffico verso servizi AI esterni, il 42% registra nuovi flussi user-to-AI e il 26% rileva un incremento del traffico east-west interno ai data center. Le architetture esistenti faticano a reggere il cambiamento. Solo il 24% dichiara di riuscire a ispezionare completamente il traffico AI senza penalizzare le performance, mentre il 76% ammette gap di ispezione o compromessi prestazionali.

Parallelamente, il 67% delle organizzazioni denuncia policy frammentate nei propri ambienti ibridi e il 64% afferma che la propria architettura necessita di redesign moderati o significativi per supportare l’AI.

I data center tornano centrali per l’AI

Un altro dato interessante riguarda il ritorno dell’on-premises. Il 29% delle organizzazioni sta già spostando workload AI verso data center privati o infrastrutture interne, mentre un ulteriore 49% sta pianificando o valutando questa possibilità. La ragione è legata a esigenze di sovranità del dato, prestazioni e controllo operativo. Il 76% delle aziende considera la sicurezza del perimetro del data center critica o mission-critical per workload AI, ma solo il 35% ritiene di essere realmente preparato a proteggerli.

Secondo il report, i data center AI stanno diventando ambienti molto diversi rispetto all’infrastruttura enterprise tradizionale, con traffico east-west elevatissimo, forte dipendenza da API e connessioni continue tra orchestrazione, storage, inferenza e servizi downstream.

La governance dell’accesso AI è completamente frammentata

Le aziende non hanno ancora trovato un modello dominante per gestire l’accesso dei dipendenti agli strumenti AI. Il 24% non applica alcun controllo specifico, il 22% si affida principalmente agli endpoint agent, il 19% utilizza regole diverse a seconda che l’utente sia on-network o off-network e un altro 19% blocca completamente gli strumenti AI esterni. Solo il 16% applica policy coerenti indipendentemente dalla posizione dell’utente.

Questo significa che lo stesso dipendente può avere livelli di protezione completamente differenti a seconda del browser, della rete o del dispositivo utilizzato.

Endpoint, SaaS e browser restano pieni di buchi e i WAF sono in crisi

Il report evidenzia forti limiti nella capacità di controllare il traffico AI SaaS. Solo il 13% delle organizzazioni riesce a ispezionare completamente e applicare policy efficaci verso servizi come ChatGPT, Gemini o Copilot. Sul fronte endpoint la situazione è persino peggiore: appena l’11% dichiara di avere piena visibilità e controllo sugli strumenti AI browser-based o installati sui dispositivi gestiti. Inoltre, il 39% afferma che i propri strumenti endpoint non coprono le applicazioni AI, mentre solo il 12% dispone di rilevamento real-time dello shadow AI sui dispositivi corporate.

Inoltre, l’intelligenza artificiale sta mettendo in crisi anche i sistemi WAF e WAAP. Solo il 22% delle aziende ritiene che i propri strumenti siano efficaci contro attacchi GenAI-specific come prompt injection o jailbreak. Il 71% segnala invece un aumento dei falsi positivi dopo l’adozione dell’AI. Secondo lo studio, i WAF tradizionali erano stati progettati per traffico web umano e pattern prevedibili, mentre i modelli generativi introducono prompt lunghi, streaming di risposte, API model-driven e interazioni service-to-service che sfuggono alle logiche storiche di inspection.

Runtime protection e testing sono ancora quasi assenti

Uno dei punti più delicati riguarda i controlli runtime sugli LLM. Solo il 17% delle organizzazioni ha distribuito in modo esteso controlli runtime come input validation, output filtering o autorizzazioni sull’utilizzo di tool da parte degli agenti AI.

Parallelamente, il 56% non possiede un processo strutturato di security testing per applicazioni GenAI oppure effettua test solo in modo occasionale. In pratica, moltissime applicazioni AI arrivano in produzione senza test sistematici contro prompt injection, adversarial input o abusi runtime.

L’AI sta creando una nuova crisi di identità e accessi, così come nella protezione dei dati

Il tema delle identità non umane emerge come uno dei principali problemi futuri. Il 48% delle organizzazioni identifica la gestione delle non-human identities come la sfida numero uno legata all’AI. Gli agenti AI utilizzano account di servizio, API key e credenziali delegate che spesso non rientrano nei tradizionali modelli IAM human-centric. Il problema è aggravato dal fatto che il 46% delle aziende non possiede alcun processo strutturato di assessment per vendor AI e solo il 7% effettua scansioni dei modelli AI prima del deployment per verificare vulnerabilità o codice malevolo.

La protezione dei dati emerge come uno dei punti più critici dell’intera ricerca. Il 25% delle aziende permette già oggi l’inserimento di codice sorgente in strumenti AI esterni, esponendo IP, configurazioni e logiche proprietarie a piattaforme con limitato controllo sull’esfiltrazione. Il 44% non riesce a tracciare il percorso dei dati sensibili una volta entrati nei workflow AI e solo il 15% dispone di sistemi DLP specificamente progettati per i flussi AI.

Secondo il report, molte aziende stanno consentendo l’ingresso di informazioni critiche nei sistemi AI senza avere lineage tracking, enforcement inline o visibilità sui movimenti downstream dei dati.

Le aziende rilevano gli attacchi AI, ma non riescono a bloccarli

Il report evidenzia una situazione particolarmente grave sul fronte prevention. Solo il 13% delle organizzazioni riesce a bloccare in tempo reale prompt malevoli o jailbreak prima che raggiungano il modello. Sul fronte della protezione dei dati, appena il 16% riesce a impedire che dati sensibili vengano inviati verso servizi AI. Ancora peggiore la situazione sugli output: soltanto il 5% è in grado di bloccare contenuti AI-generated pericolosi prima che raggiungano utenti o sistemi downstream.

Per Check Point, questo dimostra che molte organizzazioni possiedono sistemi di detection, ma non veri meccanismi di prevenzione inline capaci di operare “a velocità di inferenza”.

I dipendenti aggirano regolarmente i controlli AI

La ricerca evidenzia anche un problema organizzativo molto concreto. Il 42% delle aziende ammette che i dipendenti bypassano i controlli di sicurezza AI quando questi rallentano il lavoro.

In pratica, utenti e team trovano scorciatoie più rapide utilizzando account personali, strumenti browser-based non autorizzati o workflow esterni ai controlli aziendali. Questo fenomeno trasforma la governance AI in un problema operativo e culturale oltre che tecnologico.

Governance AI: responsabilità diffuse e poca enforcement

La governance emerge come uno degli aspetti più immaturi. Il 44% attribuisce la responsabilità AI al CISO, il 40% a comitati cross-funzionali e il 36% al CIO o all’IT leadership. Solo il 14% possiede un responsabile AI security dedicato.

Ancora più significativo è il fatto che il 45% abbia policy AI documentate, ma appena il 14% le faccia rispettare e auditare realmente.

Nel frattempo cresce la pressione normativa legata a framework come AI Act europeo e NIST AI RMF: soltanto il 7% si considera pienamente preparato.

Il mercato si sta muovendo verso piattaforme unificate

Nonostante le difficoltà, il report evidenzia una direzione molto chiara del mercato. Il 75% delle organizzazioni ha modificato la propria strategia architetturale a causa dell’AI e il 52% sta aumentando il budget dedicato alla sicurezza AI.

L’86% considera fondamentale una gestione unificata della sicurezza tra data center, cloud ed edge, mentre il 37% sta già consolidando strumenti e piattaforme verso modelli più centralizzati.

Secondo Check Point, il futuro della sicurezza AI passerà sempre più attraverso architetture “Hybrid Mesh Network Security”, capaci di distribuire policy coerenti, ispezione inline e controlli runtime attraverso ambienti cloud, endpoint, SaaS e data center.

---

• AI data leakage, AI governance, AI runtime security, AI SaaS security, AI security, AI threat landscape, AI workload protection, Check Point report AI, cloud security 2026, GenAI security, prompt injection, shadow AI aziende, sicurezza agenti AI, sicurezza intelligenza artificiale

---

---

https://www.securityinfo.it/2026/05/28/il-78-delle-aziende-ha-gia-subito-o-sospetta-incidenti-legati-allia/?utm_source=rss&utm_medium=rss&utm_campaign=il-78-delle-aziende-ha-gia-subito-o-sospetta-incidenti-legati-allia

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

---

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

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

Dalla SEO poisoning ai chatbot AI

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

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

Come funziona la catena di infezione

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

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

Il ruolo crescente della SEO poisoning nell’ecosistema malware

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

---

---

---

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

Mag 25, 2026 Stefano Silvestri Approfondimenti, Attacchi, Hacking, In evidenza, Minacce, Privacy, Scenario, Software, Tecnologia, Vulnerabilità 0

---

Un volto reale può essere modificato dall’intelligenza artificiale invecchiandolo, ringiovanendolo o alterandolo talmente tanto da perdere la somiglianza con l’originale. A un osservatore umano sembrerà quello di un’altra persona ma, per alcuni sistemi di riconoscimento facciale, quel volto può continuare a corrispondere alla stessa identità.

È il risultato mostrato da Kaspersky durante HORIZONS, la principale conferenza europea dell’azienda, in una dimostrazione condotta dal Global Research and Analysis Team, il GReAT.

I ricercatori hanno elaborato fotografie di volti reali con strumenti di intelligenza artificiale generativa, simulando scenari di invecchiamento e ringiovanimento. In molti casi le immagini prodotte sono apparse ai giornalisti presenti come ritratti di persone diverse, ma il sistema di riconoscimento facciale ha continuato ad associarle alle identità originali in dieci casi di test indipendenti.

Il punto, per Kaspersky, è duplice. Da una parte l’esperimento conferma che alcuni sistemi biometrici non si basano sulla semplice somiglianza visiva, ma su caratteristiche geometriche e strutturali del volto.

Dall’altra, proprio queste caratteristiche possono essere conservate anche in immagini sintetiche generate a partire da fotografie reali, creando un rischio per i sistemi automatici di verifica dell’identità.

Maher Yamout, Lead Security Researcher del Global Research and Analysis Team di Kaspersky, lo ha definito “una prova di fattibilità di un potenziale attacco basato sull’intelligenza artificiale”, precisando che l’esperimento non costituisce uno studio su larga scala.

La conseguenza pratica, ha spiegato, è che “le trasformazioni facciali generate dall’IA possono preservare l’identità biometrica anche quando la percezione umana interpreta le immagini come individui completamente diversi”.

Perché la macchina non vede quello che vediamo noi

Per capire il problema bisogna distinguere due passaggi che spesso vengono confusi. Il primo è il rilevamento facciale: il sistema analizza un’immagine e stabilisce se al suo interno è presente un volto.

Il secondo è la verifica facciale: una volta individuato il volto, il sistema lo confronta con un’immagine di riferimento e valuta se appartiene alla stessa persona.

Nel suo intervento, Yamout ha spiegato che la macchina non “capisce” un volto nel modo in cui lo fa un essere umano. Non interpreta la pelle, l’espressione, l’impressione complessiva o la somiglianza visiva.

Il sistema individua l’area del volto, ne estrae caratteristiche e le converte in matrici matematiche. A quel punto confronta numeri, distanze e soglie di similarità.

Questo spiega perché un’immagine modificata dall’IA può apparire molto diversa a una persona, ma risultare ancora abbastanza vicina all’originale per un modello di riconoscimento.

L’intelligenza artificiale può cambiare l’età apparente, la texture della pelle, gli occhiali, alcuni dettagli estetici o lo stile dell’immagine, ma conservare elementi geometrici e strutturali sufficienti per superare il confronto biometrico.

Nella nostra intervista, avvenuta successivamente alla presentazione, Yamout ha riassunto il punto in modo molto diretto: “Le macchine non capiscono la pelle, non capiscono le fotografie”.

I modelli, ha spiegato, cercano elementi come occhi, naso e bocca, individuano l’area del volto e la trasformano in numeri. “Quello che siamo riusciti a fare è stato cambiare l’aspetto visibile del volto ma mantenere intatta la struttura sottostante”.

Uno degli esempi più efficaci mostrati durante la presentazione riguardava un’immagine trasformata in uno stile illustrato simile a quello dello Studio Ghibli. A un osservatore umano non verrebbe naturale accettarla come prova di identità in un sistema di sicurezza.

Eppure, secondo Yamout, sette modelli su otto l’hanno comunque riconosciuta come riferibile alla stessa persona.

È un dettaglio aneddotico, che però rende bene la distanza tra la percezione umana e il calcolo biometrico.

KYC, onboarding e verifica dell’identità

Il tema diventa particolarmente rilevante nei processi di verifica dell’identità. Tra questi rientra il KYC, acronimo di “Know Your Customer”, cioè l’insieme delle procedure con cui banche, fintech, piattaforme finanziarie e altri soggetti verificano l’identità di un cliente prima di attivare un servizio o autorizzare determinate operazioni.

In molti casi l’utente carica un documento, scatta una foto o registra un breve video; il sistema confronta poi quei dati con un’immagine di riferimento.

Yamout ha indicato le università e le istituzioni finanziarie tra gli ambiti in cui possono essere ancora usate forme di verifica facciale bidimensionale.

È difficile misurarne la diffusione precisa, ha osservato, perché si tratta di una tecnologia comune, integrata in molti ambienti con motori, modelli e configurazioni differenti.

Il rischio più concreto riguarda gli scenari in cui un attaccante non genera un volto casuale ma parte da una fotografia reale.

Nella conferenza stampa Yamout ha parlato di immagini “seeded”: il modello riceve un’immagine iniziale e produce una variante sintetica, modificata secondo le istruzioni dell’operatore.

Questo rende l’attacco più mirato, perché l’immagine artificiale conserva una relazione matematica con il volto originale.

La conseguenza è che la verifica umana e quella algoritmica possono differire. Un operatore potrebbe considerare sospetta o non corrispondente un’immagine che il sistema giudica invece compatibile.

Oppure, in uno scenario automatizzato, una piattaforma potrebbe accettare un’immagine sintetica perché la distanza matematica rispetto al volto di riferimento rimane entro la soglia prevista dal modello.

Secondo Yamout, gli attaccanti partono sempre dallo studio dell’ambiente che vogliono colpire. Cercano di capire quali sistemi vengono usati, quali utenti sono coinvolti, quali software sono presenti e quali abitudini operative esistono all’interno dell’organizzazione.

Se scoprono che una procedura di verifica facciale usa un modello vulnerabile a immagini sintetiche o deepfake, quella procedura può diventare un punto d’ingresso.

La biometria resta utile, ma non basta da sola

Il messaggio di Yamout, però, non è che il riconoscimento facciale debba essere abbandonato.

Nell’intervista ha usato un paragone molto chiaro: le password continuano a essere usate anche se possono essere violate; i token di autenticazione a due fattori continuano a essere usati anche se possono essere sottratti con tecniche di phishing; gli antivirus continuano a essere distribuiti anche se esistono malware capaci di aggirarli.

La logica è la stessa per il riconoscimento facciale. Il riconoscimento facciale può ancora servire ma da solo non basta più a confermare un’identità. Deve essere affiancato da altri controlli, soprattutto nei processi più sensibili.

“Dobbiamo smettere di usarlo? No. È una buona misura di sicurezza”, ha spiegato Yamout. Il punto è affiancarla ad altri controlli compensativi: password, token, codici, verifica del dispositivo, analisi del comportamento, controlli documentali e procedure di escalation quando emergono anomalie.

Questa logica vale soprattutto per i sistemi 2D. Yamout ha distinto questi scenari dal riconoscimento facciale usato ad esempio dagli smartphone, che si basa su scansioni 3D e quindi su una tecnologia più difficile da aggirare.

Anche in quel caso, ha ricordato, sono stati discussi tentativi di attacco tramite modelli tridimensionali del volto, ma il costo operativo è molto più alto. E nella sicurezza informatica, l’aumento del costo dell’attacco è già una forma di protezione.

È qui che torna il concetto di difesa in profondità. Se un sistema richiede password, token e verifica facciale, diventa più difficile aggirare tutto insieme. L’attaccante può riuscire a compromettere un fattore ma deve investire più tempo e più risorse per superarli tutti.

E spesso, ha detto Yamout, si sposta su un bersaglio più facile: “Gli attaccanti, alla fine, sono pigri”.

Le vecchie serrature vanno aggiornate

L’esperimento di Kaspersky non dice che ogni sistema di riconoscimento facciale sia facilmente aggirabile, né che la biometria abbia perso utilità.

Mostra però che immagini, audio e video generati dall’intelligenza artificiale stanno cambiando le regole della verifica dell’identità, costringendo aziende, sviluppatori e responsabili della sicurezza a ripensare molti processi oggi dati per affidabili.

Per anni il volto è stato trattato come un elemento forte dell’identità, perché difficile da replicare e immediato da verificare.

L’IA ha cambiato i termini del problema: può produrre immagini che confondono l’essere umano, preservano elementi biometrici rilevanti per la macchina e aprono nuovi scenari per frodi, identità sintetiche e manipolazioni nei processi di onboarding.

La risposta più solida passa da sistemi capaci di combinare più segnali. La verifica facciale deve essere accompagnata da controlli sulla provenienza dell’immagine, analisi del rischio, verifica del dispositivo, controlli antifrode e procedure manuali nei casi dubbi.

Dove la posta in gioco è alta, affidarsi a un singolo fattore espone a un rischio crescente.

---

---

---

https://www.securityinfo.it/2026/05/25/kaspersky-la-genai-mette-alla-prova-il-riconoscimento-facciale/?utm_source=rss&utm_medium=rss&utm_campaign=kaspersky-la-genai-mette-alla-prova-il-riconoscimento-facciale

Mag 22, 2026 Stefano Silvestri Approfondimenti, Attacchi, Campagne malware, Gestione dati, Hacking, In evidenza, Malware, Minacce, Scenario, Software, Tecnologia, Vulnerabilità 0

---

Gli agenti di intelligenza artificiale sono ormai entrati nel radar dei criminali informatici. Dall’inizio dell’anno, infatti, Kaspersky ha rilevato a livello mondiale oltre 92.000 attacchi malware camuffati da servizi e agenti IA.

Il dato è stato presentato a Roma durante Kaspersky HORIZONS, e racconta bene quanto rapidamente l’hype sull’intelligenza artificiale sia stato metabolizzato anche dal cybercrime. Tant’è che le false applicazioni di ChatGPT rappresentano il 49% degli attacchi rilevati, mentre Claude e Gemini incidono ciascuno per il 18%.

Accanto ai nomi più noti, i ricercatori hanno individuato oltre 15.000 file malevoli distinti mascherati da software di IA autonoma, comprese versioni contraffatte di strumenti emergenti come OpenClaw.

Il punto, però, non è soltanto che i criminali usino l’IA come nuova esca. Nel suo intervento, Dmitry Galov, Head of Kaspersky’s Global Research & Analysis Team per Russia e CIS, ha spiegato che dietro molti di questi falsi strumenti si nascondono malware già noti.Ci riferiamo a banking trojan, spyware, infostealer, exploit e downloader in grado di installare ulteriori payload dannosi.

La novità sta nella confezione: gli attaccanti sfruttano la fiducia nei brand dell’IA e la curiosità verso strumenti percepiti come indispensabili per restare al passo.

La supply chain dell’IA diventa un bersaglio

Un’altra area di rischio riguarda la supply chain del software. Galov ha citato il caso di LiteLLM, una libreria Python ampiamente usata per accedere a modelli di intelligenza artificiale, con circa 97 milioni di download mensili.

La compromissione della libreria ha permesso di inserire codice dannoso capace di sottrarre credenziali di database, file di wallet di criptovalute e altre informazioni sensibili. È un esempio concreto di come un singolo componente esterno, se compromesso, possa trasformarsi in un punto d’ingresso verso molte organizzazioni contemporaneamente.

Galov ha chiarito nell’intervista che il problema non riguarda solo l’IA. Qualsiasi software moderno può dipendere da librerie, pacchetti open source o componenti di terze parti. Nel caso dell’intelligenza artificiale, però, l’ecosistema si sta sviluppando a grande velocità, in modo aperto e collaborativo, e questo rende più appetibili le dipendenze esterne.

Per ridurre il rischio, secondo Galov, serve integrare la sicurezza in tutto il ciclo di sviluppo del software: ogni pacchetto esterno introdotto in un prodotto o in un’infrastruttura deve essere controllato da motori di rilevamento e gestito con policy chiare.

Per gli aggiornamenti non legati alla sicurezza, ha suggerito anche una finestra di “cool down”, evitando di adottare automaticamente l’ultima versione appena pubblicata. Molti attacchi alla supply chain, ha spiegato, restano attivi per finestre molto brevi, da pochi minuti a qualche giorno, prima di essere individuati dalla comunità open source o dai vendor di sicurezza.

ClickFix e la vecchia debolezza umana

La corsa agli strumenti di IA ha riattivato anche tecniche di ingegneria sociale più classiche. Galov ha citato il caso degli attacchi ClickFix, in cui falsi tutorial o documentazioni apparentemente legittime convincono l’utente a copiare e incollare un comando nel terminale.

L’utente pensa di installare un componente, configurare un ambiente o migliorare le prestazioni di uno strumento, in realtà esegue una stringa malevola. Il meccanismo è particolarmente efficace perché colpisce sviluppatori, tecnici e persone che stanno cercando guide pratiche per entrare nel mondo degli agenti IA.

Nella nostra intervista, successiva alla presentazione, Galov ha ricondotto questi attacchi a una dinamica nota: le esche cambiano ma la natura umana resta la stessa. Gli utenti tendono a fidarsi di ciò che percepiscono come utile, urgente o di valore.

Sul primo gesto, cioè copiare, incollare e premere Invio, la tecnologia può fare ben poco. La difesa può però intervenire negli stadi successivi, con soluzioni di rilevamento e risposta sugli endpoint (EDR) e altri livelli di protezione capaci di bloccare l’esecuzione o riconoscere comportamenti malevoli prima che l’attacco raggiunga il suo obiettivo finale.

Skill, plugin e falsi strumenti legittimi

Il rischio non si esaurisce nei malware travestiti da app IA. Kaspersky segnala anche la crescita delle “malicious skills”, cioè funzionalità dannose nascoste all’interno dei flussi di lavoro basati sull’intelligenza artificiale.

Possono presentarsi come plugin, prompt o estensioni apparentemente innocue, in realtà sono progettate per esfiltrare dati, fare ricognizione o manipolare risultati.

È un passaggio importante perché sposta il tema dalla protezione del singolo endpoint alla sicurezza dell’intero ecosistema agentico. OpenClaw, citato sia nel comunicato sia durante l’intervento, diventa in questo senso un esempio del nuovo perimetro da controllare.

Gli agenti IA possono essere estesi con skill e plugin, e queste estensioni possono a loro volta scaricare dipendenze, interagire con strumenti locali o collegarsi a servizi esterni.

La domanda di sicurezza non riguarda quindi solo il modello ma tutto ciò che gli viene connesso: codice, permessi, API, dipendenze e automazioni.

Gli agenti aumentano l’efficienza, ma anche l’esposizione

Nel corso della nostra intervista, Galov non ha proposto una lettura allarmistica. Anzi, ha definito gli agenti IA un grande vantaggio per l’efficienza, anche nella cybersecurity e nei SOC, soprattutto quando aiutano ad automatizzare attività ripetitive. Il problema nasce quando vengono adottati senza una postura di sicurezza adeguata.

La sua analogia è semplice: passare da carta e penna a un laptop aumenta senz’altro l’efficienza, ma anche il rischio di vulnerabilità. La scelta non è tra innovazione e sicurezza, ma tra automazione governata e automazione lasciata senza controllo.

Una posizione, questa, che troviamo anche nei comunicati di Kasperky: “L’introduzione di agenti di intelligenza artificiale negli ambienti aziendali cambia la natura stessa della fiducia. Ogni azione automatizzata diventa parte di una catena più ampia di sistemi e scambi di dati”.

Il nuovo controllo passa da dati, decisioni e log

Non corso dell’intervista, non ci è  restato che chiedere a Galov delle possibili contromisure. Per Galov le aziende devono concentrarsi su due piani: data management e decision management.

Il primo riguarda i dati a cui l’agente può accedere: bisogna verificare che siano davvero necessari per il compito assegnato e che non venga concesso più di quanto serva.

Il secondo riguarda le azioni che l’agente può compiere: per le decisioni più sensibili deve restare una validazione umana, una sorta di secondo fattore in cui il controllo finale torna a una persona.

A questo si aggiunge la visibilità sull’infrastruttura intorno agli agenti, che comunicano con modelli esterni, tool di terze parti e API.

Per questo, secondo Galov, le aziende devono raccogliere log ed eventi, integrarli in sistemi SIEM e metterli a disposizione dei SOC analyst. Il rischio peggiore è che qualcosa accada senza sapere chi lo ha fatto, quale componente lo ha eseguito e quali dati o sistemi siano stati coinvolti.

È lo stesso principio che Kaspersky riassume nelle sue raccomandazioni: standardizzare interfacce e protocolli, applicare il principio del minimo scambio necessario di dati, identificare chiaramente utenti, agenti e servizi IA, mantenere la supervisione umana nei processi critici e procedere con implementazioni graduali, includendo eventuali rollback.

---

---

---

https://www.securityinfo.it/2026/05/22/kaspersky-agenti-ia-cambiano-fiducia-aziendale/?utm_source=rss&utm_medium=rss&utm_campaign=kaspersky-agenti-ia-cambiano-fiducia-aziendale

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

---

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

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

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

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

Un blackout nazionale causato da traffico di rete malevolo

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

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

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

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

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

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

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

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

Huawei e il problema della trasparenza nelle vulnerabilità enterprise

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

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

---

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

---

---

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

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

---

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

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

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

Cos’è MSHTA e perché esiste ancora in Windows

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

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

Come gli attaccanti usano MSHTA nelle campagne malware

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

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

Il ritorno dei LOLBIN e la crisi delle difese tradizionali

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

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

Perché MSHTA è ancora così efficace contro le aziende

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

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

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

La sfida futura: eliminare il legacy senza rompere Windows

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

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

---

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

---

---

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

Mag 11, 2026 Redazione Attacchi, In evidenza, News, RSS 0

---

La corsa all’AI sta creando nuove superfici di attacco e i cybercriminali stanno iniziando a sfruttarle con tecniche sempre più sofisticate. L’ultimo caso arriva dal mondo dei modelli open source e delle piattaforme collaborative dedicate all’intelligenza artificiale: un repository malevolo pubblicato su Hugging Face è riuscito a spacciarsi per un progetto ufficiale di OpenAI, raggiungendo rapidamente la vetta dei contenuti più popolari prima di essere rimosso.

Secondo quanto riportato da The Hacker News, il repository fraudolento imitava il progetto “privacy-filter” di OpenAI, copiandone descrizione e struttura per convincere sviluppatori e ricercatori a scaricare codice malevolo. L’obiettivo finale, come avviene sempre più spesso negli attacchi alla catena del software, era il furto di credenziali, cookie di sessione e dati sensibili dai browser Windows delle vittime.

L’attacco alla fiducia dell’ecosistema AI open source

La vicenda mostra come l’ecosistema AI stia vivendo una dinamica molto simile a quella già osservata negli anni nel mondo dei package npm, PyPI e GitHub. I criminali non devono necessariamente violare infrastrutture complesse: spesso basta sfruttare la fiducia implicita che sviluppatori e ricercatori ripongono nei repository pubblici.

Nel caso specifico, gli attaccanti hanno creato un progetto chiamato “Open-OSS/privacy-filter”, estremamente simile a quello reale pubblicato da OpenAI. Il repository riprendeva testi, descrizioni e struttura del progetto originale, rendendo difficile per molti utenti distinguere il repository legittimo da quello malevolo.

Secondo le analisi, il repository sarebbe riuscito a ottenere centinaia di migliaia di download prima della rimozione, sfruttando anche account fake e meccanismi di trending della piattaforma.

Come funzionava il malware nascosto nel repository

Il cuore dell’attacco era un file Python apparentemente innocuo chiamato “loader.py”. Dietro codice, che simulava normali funzioni AI, il file nascondeva una catena di infezione progettata per scaricare ed eseguire un infostealer sviluppato in Rust.

L’analisi tecnica evidenzia diversi elementi tipici delle moderne campagne malware. Uno dei primi passaggi consisteva nella disattivazione della verifica SSL, scelta che permetteva al codice di contattare server remoti senza controlli rigorosi sui certificati.

Successivamente il malware decodificava dinamicamente URL in Base64 e recuperava payload esterni contenenti comandi PowerShell eseguiti in background. Da lì veniva scaricato il componente finale dell’attacco: un infostealer compilato in Rust, linguaggio sempre più utilizzato nel cybercrime moderno perché più difficile da analizzare e facilmente utilizzabile su più piattaforme.

Una volta attivo, il malware cercava informazioni nei browser Chromium e Gecko-based, inclusi Chrome, Edge e Firefox. Nel mirino finivano password salvate, cookie, token di autenticazione e sessioni attive, informazioni particolarmente preziose per compromettere account cloud, piattaforme AI e servizi enterprise.

Il nuovo problema: modelli AI come vettore di supply chain attack

Il caso conferma una tendenza che molti ricercatori stanno osservando da mesi: le piattaforme AI stanno diventando un nuovo terreno di supply chain attack.

Hugging Face, come GitHub nel mondo software tradizionale, si basa su un modello estremamente aperto. Chiunque può pubblicare modelli, dataset e codice. Questa apertura accelera l’innovazione, ma crea anche un ambiente ideale per campagne di impersonificazione, typosquatting e distribuzione malware.

Il problema è amplificato dalla velocità con cui le aziende stanno adottando strumenti AI. Molti sviluppatori scaricano modelli e repository senza effettuare verifiche approfondite sull’autore, sulle dipendenze o sul codice eseguito localmente. Il risultato è che la fiducia nell’ecosistema open source AI rischia di diventare un nuovo punto debole della sicurezza enterprise. Non a caso, negli ultimi mesi si sono moltiplicati gli incidenti legati a modelli malevoli, package compromessi e strumenti AI distribuiti con payload nascosti.

Perché gli infostealer sono così pericolosi nel mondo AI

Gli infostealer rappresentano oggi una delle categorie malware più redditizie per i cybercriminali. Nel contesto AI, il loro valore cresce ulteriormente perché gli sviluppatori tendono ad avere accesso privilegiato a infrastrutture cloud, repository di codice e piattaforme di training. Un singolo account compromesso può consentire attacchi a catena contro pipeline CI/CD, modelli proprietari, dataset sensibili e infrastrutture cloud aziendali. Cookie di sessione e token API possono inoltre permettere agli attaccanti di bypassare MFA e altri controlli tradizionali.

In pratica, il furto di credenziali da un laptop di sviluppo può diventare il punto di partenza per compromissioni molto più ampie, incluse intrusioni nella supply chain software o manipolazioni di modelli AI distribuiti pubblicamente.

---

• AI security, browser cookie, credential theft, cybercrime, cybersecurity, hugging face, infostealer Rust, loader.py, malware AI, malware Windows, openai, repository malevoli, supply chain attack

---

---

https://www.securityinfo.it/2026/05/11/falso-repository-openai-su-hugging-face-distribuisce-malware/?utm_source=rss&utm_medium=rss&utm_campaign=falso-repository-openai-su-hugging-face-distribuisce-malware

Mag 08, 2026 Redazione In evidenza, News, RSS, Tecnologia 0

---

L’intelligenza artificiale sta, ovviamente e progressivamente, cambiando anche il modo in cui vengono condotte attività di reconnaissance, threat intelligence e analisi offensiva. Accanto ai tradizionali strumenti OSINT, stanno emergendo nuovi progetti che vanno oltre la pura automazione e puntano sulla capacità di guidare i Large Language Model attraverso metodologie operative strutturate. Uno degli esempi più interessanti è Claude-OSINT, progetto pubblicato su GitHub dallo sviluppatore “ElementalSoul” e pensato per trasformare Claude Code in una piattaforma di supporto avanzata per analisti di sicurezza, red teamer e bug bounty hunter.

Il progetto non introduce un nuovo scanner o un motore di intelligence autonomo. La sua forza risiede invece nella capacità di modificare il comportamento operativo del modello AI, fornendogli workflow, metodologie investigative, tecniche di enumerazione e processi di analisi tipici di un professionista della sicurezza offensiva.

Un nuovo approccio all’OSINT basato sugli LLM

A differenza dei framework OSINT tradizionali, Claude-OSINT non si presenta come un insieme di utility standalone. Il progetto sfrutta infatti il sistema di “skill” di Claude Code per estendere il contesto cognitivo del modello.

In pratica, il sistema inserisce all’interno dell’ambiente operativo di Claude una serie di istruzioni strutturate che insegnano al modello come affrontare attività di reconnaissance. Questo significa che Claude non si limita più a rispondere genericamente alle richieste dell’utente, ma inizia a seguire processi logici, sequenze investigative e metodologie di analisi coerenti con le pratiche del mondo offensive security.

Il repository contiene principalmente due aree operative: osint-methodology e offensive-osint. La prima definisce il modo in cui il modello deve ragionare durante la raccolta delle informazioni, mentre la seconda include template operativi, query, pattern regex, strategie di enumerazione e workflow tattici.

Uno strumento per risparmiare tempo in maniera sensata

Per chi lavora nella cybersecurity offensiva, la fase di reconnaissance rappresenta spesso una delle attività più lunghe e dispersive. Identificare asset, correlare informazioni, individuare superfici di attacco e classificare le priorità richiede tempo e competenze avanzate.

Claude-OSINT prova a intervenire proprio su questo punto, aiutando il modello AI a organizzare metodicamente le attività di raccolta delle informazioni. Secondo la documentazione del progetto, il framework include decine di moduli dedicati all’asset discovery, numerosi pattern regex per l’identificazione di secret leakage e una vasta raccolta di query e dork utilizzabili durante le indagini OSINT.

L’obiettivo è trasformare Claude in una sorta di “copilota cognitivo” capace di assistere il professionista nella costruzione di mappe relazionali, nella ricerca di endpoint interessanti e nell’identificazione di possibili punti di esposizione.

Come funziona il sistema di skill

Dal punto di vista tecnico, Claude-OSINT si basa sul sistema di skill supportato da Claude Code. Le skill sono file markdown strutturati, generalmente denominati SKILL.md, che vengono caricati all’interno dell’ambiente del modello per modificarne il comportamento operativo.

Questo significa che il framework non altera direttamente il modello AI, ma agisce tramite prompt engineering avanzato e knowledge injection contestuale. Una volta installate le skill, Claude acquisisce nuove capacità procedurali e metodologiche, imparando a seguire workflow specifici durante le attività di analisi.

Il progetto include procedure per la gestione del tempo investigativo, classificazione degli asset, prioritizzazione delle attività, correlazione delle informazioni e costruzione di report operativi. Sono presenti, inoltre, workflow dedicati all’enumerazione di domini, sottodomini, endpoint e possibili esposizioni di credenziali.

Dal punto di vista architetturale, questo approccio rappresenta un esempio molto interessante di “augmentation layer”: invece di creare un nuovo motore AI, il progetto costruisce uno strato specialistico sopra un modello generalista già esistente.

Installazione e avvio dell’ambiente

Per utilizzare Claude-OSINT è necessario avere accesso a Claude Code, l’ambiente CLI sviluppato da Anthropic per interagire con i modelli Claude.

L’installazione può essere eseguita tramite script ufficiali disponibili per Linux, macOS e Windows. Una volta configurato l’ambiente, il repository GitHub va clonato localmente e le directory contenenti le skill devono essere copiate nella cartella dedicata di Claude.

Dopo il caricamento delle skill, il modello può iniziare a utilizzare i workflow OSINT definiti dal framework. In pratica, l’utente interagisce normalmente con Claude, ma il comportamento del modello viene guidato dalle metodologie e dai processi introdotti dal progetto.

I limiti e i rischi di uno strumento del genere

Gli stessi autori del progetto sottolineano come Claude-OSINT debba essere utilizzato esclusivamente in contesti autorizzati di red teaming, penetration testing e bug bounty.

Ed è un punto cruciale, perché sistemi di questo tipo possono ridurre significativamente la barriera di accesso ad attività OSINT avanzate. Automatizzare parte del processo investigativo significa infatti aumentare velocità, capacità di correlazione e profondità dell’analisi anche per operatori meno esperti.

Questo apre inevitabilmente interrogativi più ampi sull’evoluzione dell’AI applicata alla cybersecurity offensiva. L’impressione è che il settore stia entrando in una nuova fase, in cui i modelli linguistici non saranno più semplici assistenti conversazionali, ma veri e propri “analisti aumentati” capaci di supportare operazioni complesse di intelligence e reconnaissance.

---

---

---

https://www.securityinfo.it/2026/05/08/ecco-il-github-per-fare-di-claude-un-operatore-osint-avanzato/?utm_source=rss&utm_medium=rss&utm_campaign=ecco-il-github-per-fare-di-claude-un-operatore-osint-avanzato

Mag 07, 2026 Redazione Approfondimenti, In evidenza, News, RSS, Scenario, Scenario 0

---

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.

---

• access broker, access governance, account compromise, Cifas, credenziali aziendali, cybercrime, cybersecurity, frodi interne, identity security, insider threat, sicurezza informatica, Zero Trust

---

---

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

Mag 06, 2026 Redazione Attacchi, In evidenza, News, RSS, Tecnologia 0

---

Un nuovo malware Linux altamente sofisticato sta attirando l’attenzione dei ricercatori di sicurezza per la sua capacità di compromettere sviluppatori software, sottrarre credenziali critiche e infiltrarsi nelle pipeline di distribuzione del software. Secondo un’analisi pubblicata da Trend Micro, il malware, battezzato Quasar Linux RAT (QLNX), rappresenta una delle minacce più avanzate emerse recentemente nel panorama Linux-oriented della cybercriminalità.

L’aspetto più preoccupante non è il livello tecnico del malware, ma il fatto che il suo obiettivo principale sia la compromissione della software supply chain, cioè l’intera catena di sviluppo e distribuzione delle applicazioni moderne.

Un malware progettato per colpire gli sviluppatori

QLNX non nasce per il cybercrime “di massa”. Non è un malware rumoroso progettato per bloccare sistemi o chiedere riscatti immediati. Al contrario, si tratta di un impianto estremamente silenzioso e persistente pensato per operazioni di lungo periodo.

Secondo i ricercatori, prende di mira soprattutto le credenziali che consentono agli sviluppatori di accedere agli ambienti più critici della filiera software moderna. Tra gli obiettivi figurano token Git, chiavi AWS, credenziali Docker Hub, token Kubernetes, chiavi PyPI e token NPM. In pratica, tutto ciò che può permettere agli attaccanti di infiltrarsi negli strumenti usati quotidianamente dagli sviluppatori. L’obiettivo è evidente: ottenere accesso agli ambienti utilizzati per la pubblicazione del software e sfruttare gli account compromessi per distribuire pacchetti malevoli tramite canali legittimi.

Si tratta di uno scenario particolarmente pericoloso perché permette ai criminali di compromettere la fiducia stessa su cui si basa l’ecosistema open source e DevOps. Un singolo maintainer violato può trasformarsi nel punto di ingresso per malware distribuiti poi a migliaia o milioni di utenti attraverso aggiornamenti apparentemente legittimi.

Il rischio supply chain continua a crescere

Negli ultimi anni gli attacchi supply chain sono diventati una delle principali preoccupazioni del settore cybersecurity. Incidenti che hanno coinvolto repository software, package manager e librerie open source hanno dimostrato quanto sia fragile l’infrastruttura digitale su cui poggia gran parte del software moderno.

Trend Micro sottolinea come l’intera architettura del malware sia stata progettata proprio per supportare questo tipo di workflow offensivo: compromissione iniziale, persistenza stealth, raccolta credenziali e successiva espansione dell’attacco verso altri sistemi.

Esecuzione in memoria e capacità anti-detection

Uno degli aspetti più sofisticati di QLNX riguarda le sue capacità di evasione. Il malware viene eseguito direttamente in memoria e può cancellarsi dal disco per ridurre le tracce lasciate sul sistema compromesso. Inoltre, altera il proprio nome di processo per mimetizzarsi meglio tra i processi Linux legittimi e rendere più difficile l’individuazione da parte degli strumenti di monitoraggio.

QLNX esegue anche attività di reconnaissance avanzata per identificare container, ambienti virtualizzati e configurazioni di sistema. Una volta installato, il malware ripulisce i log e nasconde attività, file, processi e porte di rete, complicando enormemente il lavoro degli analisti forensi.

Questo approccio rende il malware particolarmente adatto a operazioni di lunga durata, in cui gli attaccanti vogliono rimanere invisibili il più a lungo possibile per massimizzare la raccolta di credenziali e informazioni sensibili.

La doppia architettura rootkit

La parte più interessante dal punto di vista tecnico è probabilmente la sua architettura rootkit a due livelli. QLNX utilizza infatti sia tecniche user space sia meccanismi più avanzati basati su eBPF, una delle funzionalità più potenti e delicate del kernel Linux moderno.

Sul lato user space, il malware sfrutta hook LD_PRELOAD tramite librerie condivise, permettendo di alterare il comportamento di processi e strumenti standard. Questa tecnica consente al malware di nascondere processi, file e porte direttamente agli strumenti di amministrazione di sistema.

Parallelamente, il malware utilizza un controller rootkit eBPF che interagisce con il sottosistema BPF del kernel Linux. Secondo Trend Micro, questa componente non contiene direttamente il programma kernel-side, ma gestisce le mappe BPF usate per memorizzare gli elementi da nascondere al sistema operativo. In pratica, il malware sfrutta il kernel stesso per occultare le proprie attività, aumentando drasticamente il livello di stealth.

Le backdoor PAM e il furto di credenziali

QLNX integra anche due differenti implementazioni di backdoor PAM, elemento che rende la minaccia ancora più critica. Le PAM, o Pluggable Authentication Modules, sono componenti fondamentali dell’autenticazione Linux. Intervenendo a questo livello, il malware riesce a intercettare credenziali in chiaro durante i processi di login e autenticazione.

Una delle implementazioni descritte dai ricercatori include persino un sistema di master password bypass, che consente agli operatori di autenticarsi senza conoscere la password reale dell’utente. Il malware è inoltre in grado di registrare dati delle sessioni SSH in uscita e raccogliere token di autenticazione direttamente dai processi dinamicamente collegati.

Oltre alle credenziali, QLNX raccoglie una grande quantità di informazioni sensibili, comprese chiavi SSH, profili browser e persino contenuti degli appunti.

Sei meccanismi di persistenza contemporanei in un framework offensivo completo

Un altro elemento che distingue QLNX è la ridondanza dei sistemi di persistenza. Il malware può mantenersi attivo attraverso sei differenti tecniche contemporaneamente, sfruttando crontab, init script, service file, desktop entry e shell profile. Questo significa che anche se una tecnica viene individuata e rimossa, il malware può continuare a sopravvivere grazie agli altri meccanismi attivi sul sistema. Secondo Trend Micro, gli operatori possono decidere dinamicamente quali tecniche utilizzare tramite istruzioni ricevute dal server di comando e controllo.

QLNX supporta ben 58 comandi differenti, trasformandosi di fatto in una piattaforma offensiva estremamente completa. Gli operatori possono interagire con shell remote, manipolare file e processi, trasferire dati, riavviare sistemi, aprire connessioni TCP, catturare schermate, registrare i tasti digitati e utilizzare credenziali SSH compromesse per muoversi lateralmente verso altri host. Questa flessibilità rende il malware adatto non solo al furto di credenziali, ma anche a operazioni più ampie di spionaggio, persistenza avanzata e compromissione infrastrutturale.

Linux sempre più nel mirino

Per anni Linux è stato percepito da molte organizzazioni come un ambiente relativamente meno esposto rispetto ai sistemi Windows. Negli ultimi tempi, però, questa convinzione sta diventando sempre meno valida.

La crescita del cloud, dei container, del DevOps e delle infrastrutture Kubernetes ha reso Linux uno dei bersagli più preziosi per gli attaccanti moderni. Malware come QLNX dimostrano come i criminali stiano investendo sempre di più nello sviluppo di strumenti avanzati specificamente progettati per ambienti Linux enterprise.

E proprio perché il malware punta direttamente agli sviluppatori e alla supply chain software, il rischio non riguarda soltanto le singole macchine compromesse, ma potenzialmente interi ecosistemi applicativi e infrastrutturali.

---

---

---

https://www.securityinfo.it/2026/05/06/quasar-linux-rat-malware-che-punta-alla-supply-chain-software/?utm_source=rss&utm_medium=rss&utm_campaign=quasar-linux-rat-malware-che-punta-alla-supply-chain-software