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 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