Quasar Linux RAT: malware che punta alla supply chain software


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.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


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




CISA avvisa: Copy Fail sfruttata per root sui sistemi Linux


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.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


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




Mini Shai-Hulud: la supply chain SAP colpita da un simil-worm


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.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


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




Honeypot intelligenti: come gli agenti AI ingannano gli attaccanti AI


Stanno arrivando, ma non nascono già pronti. Stiamo parlando degli agenti AI progettati per compiere attacchi informatici. Sebbene si legga in giro che sono già in uso e sembri una tragedia, la realtà è che la tragedia deve ancora arrivare. Al momento gli attacchi basati su agenti AI sono all’inizio della loro carriera e vengono rintuzzati abbastanza facilmente. In futuro, però, non sarà così e allora sia la benvenuta una ricerca pubblicata da Cisco Talos Intelligence Group  che mostra come la stessa AI possa essere utilizzata per ribaltare completamente il paradigma difensivo, trasformando i sistemi vulnerabili in trappole intelligenti. Il concetto alla base è tanto semplice quanto interessante: utilizzare modelli generativi per creare honeypot capaci non solo di simulare vulnerabilità, ma di interagire dinamicamente con gli attaccanti, adattandosi al loro comportamento in tempo reale.

Dalla difesa passiva alla deception attiva

Gli honeypot non sono certo una novità. Da anni vengono utilizzati per attirare attaccanti e studiarne le tecniche, ma tradizionalmente si tratta di sistemi statici, limitati nella loro capacità di simulare ambienti reali. La ricerca di Talos introduce un cambio di paradigma: grazie all’AI, gli honeypot diventano sistemi dinamici in grado di mascherarsi come infrastrutture vulnerabili credibili e interagire con l’attaccante in modo realistico.

Il risultato è un livello di inganno molto più sofisticato. L’attaccante non si trova più davanti un sistema “finto” facilmente riconoscibile, ma un ambiente che reagisce, risponde e si evolve. L’architettura descritta da Talos si basa su tre componenti chiave, che insieme costruiscono un sistema di difesa completamente nuovo.

Il primo elemento è un listener di rete che accetta connessioni e simula la presenza di un servizio vulnerabile. Il secondo è una vulnerabilità “pilotata”, progettata per concedere accesso controllato all’attaccante e mantenerlo all’interno dell’ambiente di analisi. Il terzo, e più innovativo, è il layer di intelligenza artificiale, che interpreta le azioni dell’attaccante e genera risposte coerenti, mantenendo viva l’illusione.

Questo approccio consente di creare sistemi altamente scalabili. A differenza degli honeypot tradizionali, che richiedono configurazioni manuali complesse, quelli basati su AI possono essere distribuiti rapidamente e replicati su larga scala, adattandosi automaticamente ai diversi scenari di attacco.

Il bersaglio sono gli agenti AI malevoli

Uno degli aspetti più interessanti della ricerca riguarda il target di queste trappole: non tanto gli hacker umani, quanto gli agenti autonomi basati su modelli linguistici. Questi agenti, sempre più diffusi, sono progettati per automatizzare attività offensive come la scansione delle vulnerabilità, l’esecuzione di exploit e la raccolta di informazioni. Il problema è che operano con una velocità e una scala difficili da gestire con i sistemi di difesa tradizionali.

Gli honeypot AI-driven permettono invece di intercettare questi agenti, studiarne il comportamento e raccogliere intelligence in tempo reale, offrendo una visibilità senza precedenti su una nuova classe di minacce emergenti.

Il valore principale di questi sistemi non è, infatti, solo difensivo, ma soprattutto analitico. Interagendo con gli attaccanti, gli honeypot intelligenti consentono di raccogliere informazioni dettagliate sulle tecniche utilizzate, sugli strumenti impiegati e sulle logiche decisionali degli agenti AI.

Il rischio della “gamification” della difesa

L’adozione di AI anche lato difesa apre però scenari complessi. Se da un lato gli honeypot intelligenti consentono di ingannare gli attaccanti, dall’altro introducono una dinamica di escalation tecnologica. Gli attaccanti potrebbero a loro volta migliorare i propri agenti per riconoscere e aggirare queste trappole, dando vita a una sorta di “corsa agli armamenti” tra AI difensive e offensive.

Questo porta a un punto chiave: la sicurezza informatica sta evolvendo verso un modello in cui macchine attaccano macchine e altre macchine cercano di ingannarle. Per le organizzazioni, questo scenario implica un cambiamento profondo nell’approccio alla sicurezza. Non è più sufficiente proteggere i perimetri tradizionali o monitorare eventi sospetti. Serve una strategia capace di affrontare minacce automatizzate, veloci e adattive.

Gli honeypot basati su AI rappresentano una possibile risposta, perché permettono di trasformare l’infrastruttura da bersaglio passivo a sistema attivo di difesa e intelligence. Tuttavia, la loro efficacia dipenderà dalla capacità di integrarli in architetture più ampie, che includano detection avanzata, risposta automatizzata e analisi comportamentale.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/29/honeypot-intelligenti-come-lai-viene-usata-per-ingannare-gli-attaccanti-automatizzati/?utm_source=rss&utm_medium=rss&utm_campaign=honeypot-intelligenti-come-lai-viene-usata-per-ingannare-gli-attaccanti-automatizzati




Reset password: una misura di sicurezza che diventa minaccia


Vi ricordate il vecchio adagio “cambia la password almeno ogni sei mesi”? Ecco, da tempo ormai questa prassi e diventata tra quelle sconsigliate da molti esperti, ma resta ancora in auge in alcuni ambienti, tanto che, secondo le analisi di Forrester, ogni reset di password può costare fino a 70 dollari all’azienda del dipendente che deve effettuarlo. Un dato che, da solo, racconta quanto questa attività sia diffusa e strutturalmente rilevante nei processi IT aziendali. Non sorprende quindi che molte organizzazioni abbiano introdotto strumenti di self-service password reset (SSPR), nel tentativo di alleggerire il carico sugli helpdesk. Purtroppo, il numero di richieste gestite manualmente resta elevato, tra onboarding agli strumenti self-service ed eccezioni operative. Inoltre, questa apparente banalità operativa nasconde però un problema molto più profondo: il reset password è uno dei punti di ingresso più sfruttati dagli attaccanti, perché consente di aggirare controlli anche avanzati come la multi-factor authentication.

Quando un reset apre la porta all’attacco

Il motivo è semplice: se un attaccante riesce a convincere un operatore a resettare una password, ottiene credenziali legittime. A quel punto, non è più necessario sfruttare vulnerabilità tecniche, perché l’accesso avviene attraverso canali perfettamente validi.

Un esempio concreto arriva dall’attacco del 2025 contro il retailer britannico Marks & Spencer. L’incidente ha avuto un impatto devastante, con la sospensione delle vendite online per cinque giorni e perdite stimate in circa 3,8 milioni di sterline al giorno.

Secondo le ricostruzioni, il gruppo Scattered Spider avrebbe ottenuto l’accesso iniziale impersonando un dipendente e contattando un service desk esterno. Un semplice reset di password ha fornito agli attaccanti credenziali valide, eliminando la necessità di qualsiasi exploit.

Dal primo accesso al dominio completo

Una volta entrati, gli attaccanti hanno sfruttato Active Directory per estrarre il file NTDS.dit, che contiene gli hash delle password di tutti gli utenti di dominio. Attraverso tecniche di cracking offline, è stato possibile recuperare ulteriori credenziali.

A quel punto, l’attacco si è trasformato in un’escalation silenziosa: movimenti laterali, utilizzo di strumenti legittimi e accessi apparentemente normali hanno consentito di espandere progressivamente il perimetro compromesso.

Quando il livello di accesso è diventato sufficiente, è entrato in gioco il ransomware, con la cifratura dei sistemi critici per pagamenti, e-commerce e logistica. Il risultato è stato un blocco operativo su larga scala, con impatti diretti su clienti e transazioni.

Il service desk come superficie d’attacco

Gli attacchi di social engineering di questo tipo sono particolarmente insidiosi perché non presentano indicatori evidenti di compromissione. Dal punto di vista dell’helpdesk, si tratta semplicemente di una richiesta di supporto come tante altre.

Ed è proprio questa normalità a rappresentare il problema: il service desk diventa un punto di accesso privilegiato per gli attaccanti, soprattutto quando i processi di verifica dell’identità si basano su informazioni facilmente reperibili o aggirabili. In assenza di controlli robusti, una richiesta apparentemente innocua può trasformarsi in un incidente critico.

Per ridurre il rischio, è necessario introdurre meccanismi di verifica che non possano essere facilmente replicati o simulati. L’operatore non deve basarsi su dati dichiarativi, ma deve attivare codici temporanei su dispositivi registrati o integrare sistemi di identità esistenti.

Il punto chiave è la standardizzazione: ogni richiesta deve seguire lo stesso processo, senza eccezioni o discrezionalità, eliminando una delle principali leve sfruttate dagli attaccant.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/23/reset-password-una-misura-di-sicurezza-che-diventa-minaccia/?utm_source=rss&utm_medium=rss&utm_campaign=reset-password-una-misura-di-sicurezza-che-diventa-minaccia




Kyber annuncia il ransomware “post-quantum”, ma…


Kyber è un gruppo ransomware relativamente recente che ha attirato un po’ di attenzione su di sé per le ultime operazioni condotte e una postura piuttosto esibizionista nel dark Web. Questa settimana, ha pubblicato un post a proposito di un attacco riuscito usando un sistema di cifratura post-quantum per bloccare i dati della vittima.  Dietro la narrativa tecnologica avanzata si nasconde, però, una realtà più complessa, in cui marketing criminale e implementazione tecnica non sempre coincidono.

Secondo l’analisi pubblicata da Rapid7, la gang ha sviluppato due varianti distinte del ransomware, entrambe utilizzate nello stesso attacco per massimizzare l’impatto su infrastrutture eterogenee.

Attacchi coordinati tra Windows e VMware ESXi

La strategia operativa di Kyber è ben precisa: colpire simultaneamente ambienti virtualizzati e server tradizionali, ogni ambiente con una versione dedicata del malware. Le due varianti analizzate condividono infatti lo stesso campaign ID e la stessa infrastruttura di pagamento basata su Tor, suggerendo l’azione di un unico affiliato.

Ci sono, però, differenze evidenti tra le due. La variante dedicata a VMware ESXi è progettata per ambienti virtualizzati enterprise, dove può censire tutte le macchine virtuali, cifrare i datastore e modificare le interfacce di gestione con messaggi di riscatto, guidando le vittime nel processo di pagamento.

Parallelamente, la versione Windows — sviluppata in Rust — prende di mira i file server e introduce anche funzionalità sperimentali per interagire con ambienti Hyper-V, ampliando ulteriormente la superficie d’attacco.

Il “falso” post-quantum e la realtà crittografica

Il punto più interessante di tutta la vicenda riguarda la presunta adozione di crittografia post-quantum. La gang pubblicizza l’uso di Kyber1024, un algoritmo di key encapsulation appartenente alla famiglia delle tecnologie post-quantum. Tuttavia, l’analisi tecnica rivela una situazione diversa. Nella variante Linux/ESXi, il post-quantum non è realmente utilizzato perché il ransomware impiega ChaCha8 per la cifratura dei file e RSA-4096 per la protezione delle chiavi, seguendo schemi già consolidati nel panorama ransomware.

Diverso il caso della variante Windows, dove Kyber1024 viene effettivamente implementato — ma con un ruolo limitato. Come chiarisce Rapid7, Kyber non cifra direttamente i dati, ma protegge le chiavi simmetriche utilizzate da algoritmi tradizionali come AES-CTR.

Il risultato è che l’introduzione del post-quantum non cambia l’impatto operativo dell’attacco. Senza la chiave privata degli attaccanti, i dati restano comunque irrecuperabili, indipendentemente dall’algoritmo utilizzato.

Tecniche di distruzione e anti-recovery sempre più aggressive

La variante Windows appare più evoluta anche per quanto riguarda le tecniche di sabotaggio dei sistemi compromessi. Il malware è progettato per eliminare ogni possibile via di recupero dei dati, attraverso una serie coordinata di azioni.

Tra queste emergono la cancellazione delle shadow copies, la disattivazione dei meccanismi di ripristino, l’interruzione di servizi critici come SQL Server ed Exchange e la rimozione dei backup. Inoltre, il ransomware procede con la pulizia dei log di sistema e del cestino, rendendo più difficile anche l’attività forense post-incidente.

Interessante — e quasi ironico — è la presenza di un mutex che sembra fare riferimento a una canzone sulla piattaforma Boomplay, un dettaglio che suggerisce un certo grado di personalizzazione o “firma” degli sviluppatori.

Resta il fatto che in questa fase Kyber sta facendo più marketing che sfoggio di capacità tecnologiche avanzate. Il motivo non è chiarissimo dal momento che non c’è alcun motivo per un gruppo ransomware di “farsi pubblicità”, ma evidentemente anche l’ego dei criminali vuole la sua parte.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/22/kyber-annuncia-il-ransomware-post-quantum-ma/?utm_source=rss&utm_medium=rss&utm_campaign=kyber-annuncia-il-ransomware-post-quantum-ma




L’App europea di verifica dell’età è stata bucata in due minuti


La nuova app europea per la verifica dell’età, presentata come soluzione privacy-friendly per l’accesso ai servizi online, è finita immediatamente sotto scrutinio e non ne è uscita bene. A poche ore dal lancio, un ricercatore di sicurezza ha dimostrato come sia possibile aggirare i meccanismi di protezione in meno di due minuti, sollevando dubbi sulla solidità dell’architettura e sulla reale efficacia del sistema.

Il progetto, promosso dalla Commissione europea, nasce con l’obiettivo di consentire agli utenti di dimostrare la propria età senza condividere dati personali con le piattaforme, riducendo la necessità di raccolta e gestione di informazioni sensibili. Un approccio che punta a coniugare compliance normativa e tutela della privacy, ma che, secondo i primi riscontri tecnici, potrebbe introdurre nuove superfici di attacco.

Un bypass semplice ma strutturale

Le criticità evidenziate non riguardano una vulnerabilità isolata, ma scelte progettuali che espongono il sistema a manipolazioni dirette da parte dell’utente. Secondo quanto emerso, l’app memorizza localmente un PIN cifrato, ma senza legarlo in modo sicuro al vault identitario che contiene i dati di verifica.

Questo dettaglio apre la strada a un attacco relativamente semplice. Modificando alcuni file di configurazione e riavviando l’applicazione, è possibile reimpostare il PIN mantenendo l’accesso alle credenziali già generate, di fatto riutilizzando dati di identità sotto un nuovo controllo di accesso. Il risultato è un sistema che accetta credenziali precedenti senza una reale validazione del contesto.

Controlli aggirabili e sicurezza “resettable”

Ulteriori criticità emergono nei meccanismi di difesa contro attacchi più aggressivi. Il sistema di rate limiting, fondamentale per prevenire tentativi ripetuti di accesso, è implementato come un semplice contatore salvato nello stesso file di configurazione modificabile. Azzerando questo valore, l’app perde memoria dei tentativi effettuati, rendendo possibili attacchi di forza bruta.

Anche l’autenticazione biometrica risulta vulnerabile. La sua attivazione è gestita tramite un flag booleano: modificandolo manualmente, è possibile disabilitare completamente il controllo, bypassando uno dei principali livelli di sicurezza previsti.

In altre parole: i controlli di sicurezza possono essere alterati direttamente dall’utente, compromettendo l’intero modello di fiducia dell’applicazione.

Un problema di design più che di bug

La reazione della comunità di sicurezza è stata immediata. Diversi esperti hanno sottolineato come il problema non sia riconducibile a un semplice bug, ma a una progettazione che non tiene conto dei principi fondamentali della sicurezza mobile.

In particolare, è stata evidenziata l’assenza di integrazione con componenti hardware sicuri, come il secure enclave presente sui dispositivi moderni, che avrebbe potuto proteggere le informazioni critiche da modifiche locali.

Altri dubbi riguardano la logica stessa del sistema, inclusa la presenza di limiti temporali sulle credenziali di età. Un approccio che solleva interrogativi sull’effettiva coerenza del modello, considerando che l’età anagrafica non è un attributo soggetto a variazioni retroattive.

Una sicurezza ancora da dimostrare

L’episodio evidenzia un punto critico per il futuro della regolamentazione digitale: la sicurezza non può essere un elemento secondario rispetto alla compliance normativa. Soluzioni progettate per proteggere gli utenti rischiano di ottenere l’effetto opposto se non supportate da architetture robuste e da una corretta implementazione dei controlli.

C’è da dire che l’approccio di rendere open source il codice dell’app testimonia la buona volontà dell’Unione e traccia un bel precedente di trasparenza e solidità. L’app, infatti, non è ancora scaricabile e la community si è attivata su Github per studiarla prima che potesse far danni. Chi è stato incaricato dello sviluppo è già al lavoro per tappare le numerose falle trovate e seguire i (saggi) consigli ricevuti dalla comunità di sicurezza.

D’altro canto, è abbastanza desolante il fatto che l’Unione costringa le aziende ad assumere una postura di sicurezza ben strutturata con norme severe e poi crei un’app che sembra un colabrodo per la gestione degli accessi online basati sull’età. Speriamo che questa cantonata insegni qualcosa per i progetti futuri.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/17/lapp-europea-di-verifica-delleta-e-stata-bucata-in-meno-di-due-minuti/?utm_source=rss&utm_medium=rss&utm_campaign=lapp-europea-di-verifica-delleta-e-stata-bucata-in-meno-di-due-minuti




Recovery scam: quando la truffa colpisce due volte


Nel panorama delle minacce informatiche, esiste una categoria di attacchi particolarmente insidiosa di cui si parla poco, ma che gode di pessima fama perché colpisce le vittime nel momento di maggiore vulnerabilità: le recovery scam, ovvero le truffe che promettono di recuperare il denaro già sottratto. Secondo Eset, si tratta di una strategia sempre più diffusa, che sfrutta dati, contesto e stato emotivo delle vittime per mettere a segno un secondo attacco dopo una prima estorsione (o furto) andata a buon fine.

Il principio è tanto semplice quanto efficace: chi è già stato truffato rappresenta un target ad alta probabilità di successo. Non a caso, secondo le stime più recenti, solo negli Stati Uniti si sono registrati oltre 7.000 casi nel 2024, con un danno economico superiore ai 102 milioni di dollari. E come spesso accade nel cybercrime, questi numeri rappresentano probabilmente solo una parte del fenomeno reale.

Le “sucker list”: il mercato nascosto delle vittime e come funziona la seconda truffa

Alla base delle recovery scam c’è un meccanismo ben rodato nel mondo del cybercrime: la condivisione di informazioni tra gruppi criminali. Le cosiddette “sucker list” funzionano come veri e propri database di potenziali vittime, contenenti nomi, contatti e in alcuni casi anche dettagli sul comportamento e sulla propensione a cadere in specifiche truffe.

Questi elenchi includono spesso persone che hanno già subito una frode o che hanno risposto a campagne di spam, rendendole particolarmente appetibili per nuovi attacchi. In pratica, la vittima entra in un circuito in cui viene continuamente esposta a tentativi di frode sempre più mirati.

Le recovery scam seguono schemi ricorrenti, basati su tecniche di social engineering e impersonificazione. Gli attaccanti si presentano come società di recupero crediti, autorità governative, forze dell’ordine o specialisti antifrode, dichiarando di poter recuperare il denaro sottratto.

Spesso dispongono già di informazioni dettagliate sulla truffa subita, elemento che aumenta la credibilità dell’attacco. A questo punto, la richiesta è quasi sempre la stessa: un pagamento anticipato per avviare la procedura di recupero, mascherato da commissione amministrativa, tassa o costo di gestione.

In altri casi, i criminali sostengono di aver già recuperato il denaro e chiedono dati bancari o informazioni su wallet crypto per procedere al rimborso. Questa variante è particolarmente pericolosa perché può portare a furti di identità, accessi non autorizzati ai conti e ulteriori frodi finanziarie.

Il ruolo del social engineering

Uno degli elementi chiave di queste truffe è la componente psicologica. I criminali sfruttano la frustrazione e il desiderio di recuperare il denaro perso, facendo leva su urgenza e pressione emotiva. Le comunicazioni sono spesso non richieste e arrivano tramite email, social network, SMS o telefonate.

Le promesse sono volutamente ambiziose, con garanzie di recupero o affermazioni secondo cui i fondi sarebbero già disponibili. In parallelo, vengono utilizzate tecniche di impersonificazione per simulare l’affidabilità di enti ufficiali, mentre i metodi di pagamento richiesti sono spesso difficili da tracciare, come criptovalute o gift card.

Questo mix di elementi rende la truffa particolarmente efficace, soprattutto nei confronti di utenti già colpiti in precedenza.

Difendersi da un attacco “di ritorno”

Dal punto di vista della sicurezza, le recovery scam rappresentano un’evoluzione delle tradizionali frodi advance fee, con un livello più alto di personalizzazione e targeting. La difesa passa innanzitutto dalla consapevolezza: nessun soggetto legittimo contatterà una vittima senza richiesta per offrire servizi di recupero fondi a pagamento anticipato.

È fondamentale verificare sempre l’identità di chi propone questi servizi attraverso canali indipendenti e diffidare da richieste di pagamento immediate. Allo stesso modo, la condivisione di informazioni personali o finanziarie deve essere evitata, soprattutto in contesti non verificati.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/16/recovery-scam-quando-la-truffa-colpisce-due-volte/?utm_source=rss&utm_medium=rss&utm_campaign=recovery-scam-quando-la-truffa-colpisce-due-volte




Supply chain: il 69% delle aziende pronto a co-finanziare la sicurezza


Sembra che il mercato inizi a considerare una cosa sensata il concetto di “sicurezza come responsabilità condivisa”. Questa frase, spesso usata in passato senza una reale presa sulla realtà e forse più come metodo per “scaricare” parte delle proprie responsabilità su altri, adesso trova dei riscontri nella nuova ricerca di Kaspersky intitolata “Supply chain reaction: securing the global digital ecosystem in an age of interdependence”. I primi numeri che saltano all’occhio, infatti, sono che, secondo le risposte date dagli oltre 1500  oltre manager e dirigenti interpellati, quasi il 70% delle aziende è pronto a investire direttamente nella sicurezza di partner e fornitori, riconoscendo quindi che il rischio cyber non è più confinato all’interno del perimetro organizzativo, mentre un ulteriore 25% ha già avviato iniziative concrete di condivisione dei costi. In altre parole, quasi un’organizzazione su quattro è già passata dalla teoria alla pratica, trasformando la protezione della supply chain in un investimento condiviso.

Attacchi in crescita: una minaccia che riguarda un’azienda su tre

La spinta verso modelli di sicurezza collaborativa è direttamente legata alla pressione degli attacchi. Il report evidenzia come quasi il 30% delle aziende sia stato colpito da attacchi alla supply chain nell’ultimo anno, mentre circa il 25% ha subito attacchi basati sullo sfruttamento di relazioni di fiducia già esistenti.

E nonostante gli attacchi siano diffusi in tutto il Pianea, l’analisi evidenzia che la propensione a investire nella sicurezza dei partner varia molto in base all’area geografica, raggiungendo l’83% in India, l’80% in Indonesia e Russia e il 76% in Brasile. Sul fronte dell’adozione concreta, i tassi più elevati si registrano a Hong Kong e Taiwan (33%), seguiti da Spagna (33%), Turchia (31%) e Vietnam (31%).

Il gap tra grandi aziende e fornitori

Alla base di questo cambiamento c’è un elemento strutturale: la disomogeneità delle capacità di sicurezza lungo la supply chain. Le grandi organizzazioni dispongono generalmente di strumenti, competenze e budget più elevati rispetto ai loro fornitori, creando punti deboli che possono essere sfruttati dagli attaccanti. Le aziende più strutturate diventano così abilitatori della sicurezza dell’intero ecosistema, contribuendo a colmare il gap e a ridurre le superfici di attacco indirette.

“Oggi le aziende si rendono conto che la sicurezza non può più limitarsi ai confini della propria organizzazione, ma deve estendersi all’intero ecosistema”, ha commentato Sergey Soldatov, Head of Security Operations Center di Kaspersky. “Le aziende più piccole spesso non dispongono delle stesse capacità di sicurezza delle grandi imprese per cui lavorano, il che comporta rischi aggiuntivi per queste ultime. Condividendo risorse e competenze, le grandi aziende possono colmare questa lacuna, rafforzando i punti deboli lungo l’intera catena di dipendenza e diventando così un motore fondamentale della resilienza informatica globale”.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/15/supply-chain-il-69-delle-aziende-pronto-a-finanziare-la-sicurezza-dei-fornitori/?utm_source=rss&utm_medium=rss&utm_campaign=supply-chain-il-69-delle-aziende-pronto-a-finanziare-la-sicurezza-dei-fornitori




Donne e cybersecurity: crescono le nuove leve e alcune sfide


La cybersecurity italiana continua a crescere, ma la presenza femminile rimane ancora sottorappresentata, competenze e responsabilità siano in aumento. La terza survey della community Women For Security, basata su 154 risposte e 25 domande, evidenzia una realtà articolata: da un lato si vede comunità professionale femminile sempre più qualificata e strutturata, dall’altro criticità persistenti su carriera, retribuzione e inclusione.

I dati mostrano innanzitutto una presenza femminile non limitata alle nuove generazioni. La fascia d’età più rappresentata è quella tra i 26 e i 35 anni (33%), ma emerge anche una quota significativa tra i 36 e i 55 anni che ci ricorda che le donne non sono entrate ieri nel settore. Dal punto di vista geografico, la Lombardia raccoglie il 41% delle risposte, seguita da Lazio (15%) ed Emilia-Romagna (12%), a conferma della concentrazione delle opportunità cyber nei principali poli tecnologici del Paese.

Il livello di formazione risulta particolarmente elevato. Il 49% delle partecipanti possiede una laurea, mentre il 38% ha conseguito master o titoli post-laurea, evidenziando un profilo professionale altamente qualificato. La formazione continua rappresenta inoltre un elemento centrale: il 46% ha seguito percorsi finanziati dal datore di lavoro, mentre il 33% ha investito personalmente nella propria crescita professionale.

La survey evidenzia anche come i percorsi di ingresso nella cybersecurity siano spesso non lineari. Il 23% delle professioniste dichiara di essersi avvicinata al settore per interesse personale, dato raddoppiato rispetto al 2022, mentre il 21% vi è entrato per caso, contro il 10% della precedente rilevazione. Questo conferma la natura multidisciplinare della sicurezza informatica e la possibilità di accesso attraverso competenze eterogenee.

Sul fronte dell’esperienza, cresce la quota di professioniste con oltre dieci anni nel settore (22%), mentre il 26% ha tra cinque e dieci anni di attività. L’area tecnica resta la più rappresentata con il 27%, ma aumentano anche ruoli in ambito legal (11% contro il 5% nel 2022), marketing (11%), commerciale e presales (9%) e project management o divulgazione. Parallelamente, aumenta la presenza in aziende private (71% contro il 64%) e raddoppia la quota di imprenditrici (4% dal 2%). Crescono anche i ruoli di responsabilità, con le posizioni manageriali che passano dal 25% al 32% e quelle dirigenziali dal 5% all’11%.

Nonostante questi segnali positivi, la cybersecurity resta un ambiente a forte predominanza maschile. Il 24% delle partecipanti considera questo contesto una sfida stimolante, mentre il 30% lo ritiene ancora un problema da risolvere. Il 23% dichiara di non aver mai vissuto la predominanza maschile come una difficoltà, ma aumenta la quota di chi la percepisce come un ostacolo concreto, che passa dal 4% al 10% rispetto alla survey precedente. Nel complesso, il 60% afferma di avere con i colleghi uomini lo stesso rapporto che con le colleghe, segno di un clima generalmente collaborativo.

Le criticità più evidenti emergono però sul fronte economico e della carriera. Il 54% delle partecipanti ritiene di percepire uno stipendio inferiore rispetto ai colleghi uomini a parità di ruolo, mentre l’87% considera la propria progressione professionale più lenta, un dato in forte aumento rispetto al 39% del 2022. Anche le opportunità di crescita risultano percepite come inferiori dal 78% delle intervistate, contro il 40% della precedente rilevazione. A questo si aggiunge la difficoltà di conciliare lavoro e vita familiare, indicata dall’88% delle partecipanti, rispetto al 48% del 2022.

Nel complesso, la survey restituisce l’immagine di una comunità di professioniste sempre più qualificata, con ruoli in crescita e maggiore presenza nel mercato, ma che deve fare i conti con un gap significativo in termini di retribuzione, carriera e inclusione. Sebbene la parità di genere non sia ostacolata in questo ambito di carriere STEM, la grave carenza di personale che attanaglia il settore della cybersecurity consiglierebbe di spingere per un reclutamento più efficace tra le donne perché rappresentano una risorsa ancora ampiamente valorizzabile.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/14/donne-e-cybersecurity-crescono-le-nuove-leve-e-alcune-sfide/?utm_source=rss&utm_medium=rss&utm_campaign=donne-e-cybersecurity-crescono-le-nuove-leve-e-alcune-sfide