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 21, 2026 Giancarlo Calzetta In evidenza, Mercato, News, RSS, Scenario 0

---

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

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

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

La rivoluzione AI sta travolgendo i bug bounty

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

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

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

HackerOne cerca di ridurre il rumore operativo

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

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

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

Il rischio di una crisi economica per i ricercatori indipendenti

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

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

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

L’effetto collaterale: meno vulnerabilità divulgate?

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

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

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

---

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

---

---

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

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

---

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

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

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

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

Un blackout nazionale causato da traffico di rete malevolo

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

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

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

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

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

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

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

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

Huawei e il problema della trasparenza nelle vulnerabilità enterprise

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

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

---

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

---

---

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

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

---

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

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

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

Cos’è MSHTA e perché esiste ancora in Windows

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

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

Come gli attaccanti usano MSHTA nelle campagne malware

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

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

Il ritorno dei LOLBIN e la crisi delle difese tradizionali

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

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

Perché MSHTA è ancora così efficace contro le aziende

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

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

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

La sfida futura: eliminare il legacy senza rompere Windows

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

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

---

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

---

---

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

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

Mag 04, 2026 Redazione Attacchi, In evidenza, News, RSS, Vulnerabilità 0

---

CISA ha inserito Copy Fail tra le vulnerabilità sfruttate attivamente, segnalando che la falla viene già usata in attacchi reali per ottenere privilegi di root su sistemi Linux non aggiornati. Il bug, archiviato come CVE-2026-31431, riguarda il sottosistema crittografico del kernel Linux e consente a un utente locale non privilegiato di modificare in modo controllato la page cache di file leggibili, inclusi binari setuid-root come /usr/bin/su. In pratica, una presenza iniziale anche limitata sul sistema può essere trasformata in controllo completo della macchina.

Perché Copy Fail è così pericolosa

Copy Fail non è una vulnerabilità remota autonoma: per sfruttarla serve già la possibilità di eseguire codice sul sistema. Questo però non la rende meno grave. In molti scenari moderni, soprattutto in cloud, CI/CD, ambienti multi-tenant e Kubernetes, l’esecuzione di codice non privilegiato è una condizione frequente. Un job malevolo in una pipeline, un container compromesso, un accesso SSH a basso privilegio o una web shell possono diventare il punto di partenza per una escalation immediata a root.

La criticità è amplificata dalla portata del bug. Secondo CERT-EU, la vulnerabilità interessa le principali distribuzioni Linux con kernel costruiti a partire dal 2017, mentre Microsoft cita tra gli ambienti impattati Red Hat, SUSE, Ubuntu e AWS Linux, oltre a un impatto potenziale su larga parte dei workload cloud Linux e dei cluster Kubernetes.

Il cuore tecnico: AF_ALG, algif_aead e page cache

La vulnerabilità si trova in algif_aead, il componente che espone agli utenti lo stack crittografico AEAD del kernel attraverso socket AF_ALG. AF_ALG è un’interfaccia legittima: consente ai processi user space di usare primitive crittografiche implementate nel kernel. Il problema nasce da un’ottimizzazione introdotta nel 2017, pensata per rendere alcune operazioni più efficienti attraverso elaborazioni “in-place”, cioè usando gli stessi buffer come sorgente e destinazione.

Quell’ottimizzazione ha introdotto una condizione anomala nella gestione delle strutture scatterlist, usate dal kernel per descrivere aree di memoria non necessariamente contigue. In presenza di una specifica combinazione di operazioni, pagine appartenenti alla page cache possono finire dentro una destinazione considerata scrivibile. Il risultato è che un utente non privilegiato può ottenere una primitiva di scrittura limitata ma controllata: quattro byte alla volta dentro la cache di un file leggibile.

Perché quattro byte bastano per ottenere root

A prima vista, una scrittura di quattro byte può sembrare troppo piccola per avere conseguenze serie. In realtà, nel contesto giusto è sufficiente. L’exploit pubblico mostra come sia possibile colpire un binario setuid-root, cioè un eseguibile che, quando viene lanciato, opera con privilegi elevati. Se l’attaccante modifica in memoria alcune istruzioni del binario, può far sì che l’esecuzione produca una shell con privilegi di root.

La sequenza sfrutta la combinazione tra socket AF_ALG e la system call splice(). Quest’ultima consente di spostare dati tra file descriptor senza copiarli nello spazio utente, ed è proprio questa interazione con la page cache a rendere possibile l’attacco. Il payload non modifica il file su disco: altera la copia in memoria che il kernel usa per servire le letture successive. Quando il binario viene eseguito, il sistema legge la versione corrotta presente in cache e l’attaccante ottiene l’effetto desiderato.

Il dettaglio più insidioso: la modifica non resta sul disco

Uno degli aspetti più pericolosi di Copy Fail è la sua natura in-memory. La pagina corrotta non viene marcata come “dirty” per la scrittura su disco, quindi il file originale rimane apparentemente intatto. Questo significa che controlli basati su checksum del file system o strumenti che confrontano i binari su disco possono non rilevare la modifica.

In termini pratici, l’attaccante può alterare temporaneamente il comportamento di un binario privilegiato senza lasciare la classica traccia di una modifica persistente al file. La compromissione avviene nella memoria del kernel, ma l’effetto è immediatamente visibile a livello di sistema perché la page cache è ciò che viene effettivamente consultato quando il file viene letto o eseguito.

Container, cloud e CI/CD: gli ambienti più esposti

La falla è particolarmente rilevante negli ambienti containerizzati. La page cache è condivisa a livello host, quindi una primitiva di corruzione della cache può avere conseguenze oltre il confine apparente del container. Secondo l’analisi tecnica pubblicata dai ricercatori, lo stesso meccanismo può attraversare boundary container perché il target reale non è il file system isolato visto dal container, ma la page cache gestita dal kernel dell’host.

Questo rende Copy Fail molto pericolosa in scenari Kubernetes e CI/CD, dove è normale eseguire codice proveniente da repository, build, test automatici o workload temporanei. Un attaccante che riesce a introdurre codice in un runner di build o in un container con privilegi minimi può usare la vulnerabilità per scalare a root sull’host, con conseguenze dirette su segreti, immagini, pipeline, credenziali cloud e altri workload presenti nello stesso ambiente. Microsoft evidenzia proprio i rischi di container breakout, compromissione multi-tenant e movimento laterale.

L’exploit è affidabile e già pubblico

Il rischio operativo è aumentato dalla disponibilità di un proof-of-concept pubblico. I ricercatori di Theori/Xint hanno descritto un exploit Python molto compatto, indicato come capace di ottenere root su Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 e SUSE 16. BleepingComputer riporta che lo stesso script viene descritto come affidabile anche su distribuzioni Linux distribuite dal 2017 con kernel vulnerabile.

La presenza di un PoC funzionante cambia il profilo di rischio. Non serve più che gli attaccanti ricostruiscano il bug partendo dalla patch o dalla descrizione tecnica: possono partire da codice già disponibile e adattarlo ai propri contesti. L’inserimento nel catalogo KEV di CISA conferma che il problema non è più solo teorico o da laboratorio, ma riguarda attività osservate nel mondo reale.

Mitigazione: aggiornare il kernel e ridurre la superficie

La risposta prioritaria è l’aggiornamento del kernel alle versioni corrette fornite dalla propria distribuzione. CERT-EU ha indicato Copy Fail come vulnerabilità ad alta gravità e ha raccomandato di dare priorità agli ambienti più esposti, in particolare nodi Kubernetes e runner CI/CD che eseguono workload non fidati.

In attesa delle patch, le organizzazioni dovrebbero valutare mitigazioni di hardening sugli ambienti dove utenti o workload non privilegiati possono eseguire codice. L’obiettivo è ridurre la possibilità di usare AF_ALG e le primitive necessarie all’attacco, monitorare l’uso anomalo di socket AF_ALG e rafforzare il controllo dei workload che possono accedere a binari setuid. Sysdig suggerisce che la creazione sospetta di socket AF_ALG, soprattutto da processi non riconducibili a tool legittimi di cifratura o gestione crypto, può diventare un segnale utile per la detection runtime.

---

• AF_ALG, algif_aead, CI/CD Security, CISA KEV, container breakout, Copy Fail, CVE-2026-31431, kernel Linux vulnerability, Kubernetes security, Linux root exploit, page cache Linux, privilege escalation Linux, setuid root, vulnerabilità Linux

---

---

https://www.securityinfo.it/2026/05/04/cisa-avvisa-copy-fail-sfruttata-per-root-sui-sistemi-linux/?utm_source=rss&utm_medium=rss&utm_campaign=cisa-avvisa-copy-fail-sfruttata-per-root-sui-sistemi-linux

Apr 30, 2026 Redazione Attacchi, In evidenza, News, RSS 0

---

La compromissione della supply chain software continua a evolvere, e l’operazione “Mini Shai-Hulud” rappresenta uno dei casi più interessanti e pericolosi osservati negli ultimi mesi. L’analisi pubblicata da Wiz evidenzia come un numero limitato di pacchetti npm compromessi sia stato sufficiente per attivare una catena di infezione capace di propagarsi tra ambienti di sviluppo, pipeline CI/CD e repository GitHub, con un livello di automazione sempre più sofisticato. L’attacco è partito ieri, 29 aprile, ma ancora oggi sono stati identificati degli npm compromessi.

Ricordiamo che l’ecosistema SAP, e in particolare il Cloud Application Programming Model, rappresenta uno dei contesti più diffusi nelle aziende enterprise. Colpire questo layer significa entrare direttamente nei processi di sviluppo che alimentano applicazioni critiche di business.

L’ingresso nella supply chain: pacchetti legittimi, codice malevolo

L’attacco si basa su una tecnica ormai consolidata nel mondo npm: la pubblicazione di versioni “trojanizzate” di pacchetti legittimi. Nel caso specifico, alcuni moduli SAP sono stati modificati introducendo uno script di preinstallazione che viene eseguito automaticamente durante l’installazione delle dipendenze. Questo dettaglio è fondamentale. Il codice malevolo non viene eseguito dopo il deploy, ma nel momento stesso in cui lo sviluppatore installa le dipendenze; quindi, all’interno di ambienti fidati come workstation locali o pipeline automatizzate.

Lo script avvia un processo in più fasi. Inizialmente viene scaricato un runtime esterno, nel caso specifico Bun, utilizzato per eseguire un payload fortemente offuscato. Questo payload, di dimensioni superiori agli 11 MB, rappresenta il cuore dell’operazione: un framework completo per il furto di credenziali e la propagazione.

Il vero obiettivo: le credenziali degli sviluppatori

A differenza di molte campagne tradizionali, l’obiettivo principale non è l’esecuzione diretta di codice malevolo sui sistemi finali, ma la raccolta sistematica di credenziali. Il malware è progettato per estrarre token e chiavi da molteplici fonti: GitHub, npm, ambienti cloud come AWS, Azure e GCP, fino a Kubernetes e vari browser. Del resto, le credenziali rappresentano oggi la chiave di accesso più efficace per compromettere infrastrutture complesse, perché consentono di muoversi lateralmente senza attivare controlli di sicurezza tradizionali.

I dati raccolti vengono cifrati e inviati verso repository GitHub controllati dagli attaccanti. Un elemento particolarmente interessante è che spesso questi repository vengono creati utilizzando le credenziali delle stesse vittime, trasformando ogni account compromesso in un ulteriore nodo di distribuzione.

Il salto di qualità rispetto ad attacchi precedenti sta nella capacità di auto-propagazione. Il malware utilizza i token raccolti per modificare repository GitHub, inserire workflow malevoli e pubblicare nuove versioni compromesse dei pacchetti.

Questo comportamento avvicina Mini Shai-Hulud a un worm, capace di espandersi autonomamente all’interno dell’ecosistema software. In alcuni casi, il codice introduce configurazioni malevole anche negli strumenti di sviluppo, come file di configurazione per ambienti come Visual Studio Code, che attivano nuovamente il payload quando il repository viene aperto.

Il risultato è una persistenza difficile da individuare. Non si tratta solo di un’infezione temporanea, ma di una contaminazione che può riattivarsi nel tempo attraverso strumenti legittimi utilizzati quotidianamente dagli sviluppatori.

Un elemento apparentemente rassicurante è la durata limitata dell’esposizione. I pacchetti compromessi sono rimasti disponibili per poche ore prima di essere rimossi e sostituiti con versioni pulite. Tuttavia, questo non riduce il rischio. Al giorno d’oggi, le pipeline CI/CD scaricano automaticamente dipendenze aggiornate e anche una finestra temporale ridotta è sufficiente per introdurre codice malevolo in ambienti produttivi o di sviluppo, da cui l’attaccante può poi espandersi. Questo aspetto evidenzia una criticità strutturale: la velocità dei processi DevOps amplifica l’impatto delle compromissioni della supply chain, riducendo il tempo disponibile per intercettarle.

Continuità con le campagne Shai-Hulud precedenti

L’operazione si inserisce in una serie di campagne già osservate negli ultimi mesi, tutte riconducibili al nome Shai-Hulud. Le analisi indicano similitudini nelle tecniche e negli strumenti utilizzati, suggerendo una continuità operativa o almeno un riutilizzo di codice e metodologie.

Rispetto alle versioni precedenti, Mini Shai-Hulud introduce miglioramenti significativi, tra cui cifratura avanzata dei dati esfiltrati e nuove tecniche di persistenza. Inoltre, emerge un elemento particolarmente rilevante: l’uso di strumenti legati allo sviluppo assistito da AI come vettori di esecuzione, segnale di come anche questi ambienti stiano diventando parte della superficie di attacco.

---

---

---

https://www.securityinfo.it/2026/04/30/mini-shai-hulud-la-supply-chain-sap-colpita-da-un-simil-worm/?utm_source=rss&utm_medium=rss&utm_campaign=mini-shai-hulud-la-supply-chain-sap-colpita-da-un-simil-worm