Claude Code Security crea il panico, ma… non uccide la cyber


Venerdì scorso Anthropic ha presentato Claude Code Security, una nuova funzione che analizza intere codebase alla ricerca di vulnerabilità e propone patch correttive. Il rilascio, per ora, è in modalità research preview limitata per clienti enterprise e team, mentre i maintainer open source possono chiedere accesso gratuito accelerato. L’effetto immediato, però, non si è visto nei bug tracker: si è visto in Borsa, con una reazione nervosa su diversi titoli cyber e un dibattito istantaneo sul “fine dei vendor di sicurezza”.

La “tempesta perfetta”: hype sull’AI, paura di disintermediazione e un mercato già nervoso

Il sell-off è stato alimentato da un’idea semplice, quasi cinematografica: se un LLM può scansionare codice e suggerire fix, allora una fetta del lavoro di sicurezza potrebbe essere automatizzata e “commoditizzata”. In realtà, analisti e osservatori hanno rapidamente raffreddato la lettura apocalittica: l’AI sta entrando in modo sempre più profondo nella sicurezza, ma non elimina i bisogni strutturali di detection, risposta, threat intel, governance e controllo del rischio. La reazione del mercato viene descritta come un’overreaction, più legata al timing e al sentiment che a un impatto immediato sui modelli di business.

Per drammatizzare, George Kurtz (CEO di CrowdStrike) ha chiesto a Claude se il nuovo strumento potesse rimpiazzare ciò che fa la sua azienda. La risposta del modello è stata sostanzialmente un “no” e il punto non è l’aneddoto in sé, ma ciò che riflette: l’AI può essere molto brava su compiti delimitati, ma la sicurezza reale è un sistema socio-tecnico fatto di contesto, priorità, trade-off e responsabilità.

“500 vulnerabilità high-severity”: un claim potente, ma il diavolo è nei dettagli

Il lancio di Claude Code Security arriva dopo che Anthropic aveva dichiarato che Claude Opus 4.6 avrebbe individuato e validato più di 500 vulnerabilità “ad alta pericolosità” in progetti open source. È un numero che colpisce l’immaginazione, perché sposta l’immagine dalla semplice individuazione di pattern alla capacità di proporre un percorso di validazione e remediation. Ma nel mondo della sicurezza contano almeno due domande: qual è il tasso di falsi positivi e qual è il costo (in risorse e in tempo) per ottenere quei risultati. Su questo, chi lavora quotidianamente su strumenti per developer security chiede più trasparenza e metriche pubbliche.

Anthropic posiziona Claude Code Security come uno strumento context-aware, capace di “ragionare” sul codice in modo simile a un ricercatore umano: “comprende” interazioni tra componenti, “segue” il movimento dei dati e intercetta bug complessi che sfuggono a regole statiche. Se la promessa regge alla prova dei fatti, l’impatto pratico potrebbe essere notevole per team che gestiscono codebase ampie e stratificate, dove la vulnerabilità non è un pattern banale ma nasce da logica di business, integrazioni e condizioni limite. Resta però un punto chiave: Anthropic dice che nessuna modifica viene applicata senza approvazione umana.

Non è un unicum: Amazon, Microsoft e Google stanno correndo nella stessa direzione

Claude Code Security è la novità “più chiacchierata”, ma non è la prima tessera del mosaico. In parallelo, praticamente tutti i grandi player stanno usando agenti AI per scoprire vulnerabilità e accelerare il ciclo di patching. Google aveva già parlato di Big Sleep come strumento LLM-based per caccia ai bug e più di recente DeepMind ha presentato CodeMender come agente per automatizzare la creazione di patch, individuare la root cause e generare una correzione verificabile. L’AI sta diventando un moltiplicatore di produttività nella sicurezza del software e questo non è un segreto per nessuno, si applica a tutti i campi, ma non è una bacchetta magica che sostituisce processi e responsabilità.

Inoltre, il vero banco di prova non è “se trova qualche bug”, ma se regge a scala industriale senza esplodere in falsi positivi, rumore e patch discutibili. Isaac Evans (Semgrep) ha centrato una questione che nella narrazione mainstream viene spesso messa in secondo piano: senza statistiche pubbliche su precision/recall, falsi positivi e costi, il rischio è che parte della comunicazione sia per lo più marketing. Anche ammesso che l’AI migliori sensibilmente la discovery, rimane il processo: triage, priorità, compatibilità, regressioni e governance del cambiamento in ambienti di produzione.

Perché “umani nel loop” non è una clausola di stile, ma un requisito di sicurezza

Il punto non è la sfiducia verso gli LLM: è la responsabilità. Una patch proposta da un modello può essere tecnicamente corretta e allo stesso tempo funzionalmente pericolosa, perché sposta un controllo, rompe un’integrazione o introduce un comportamento inatteso. Inoltre, gli stessi modelli che aiutano a trovare vulnerabilità possono anche produrre codice fragile o aprire nuovi vettori, soprattutto quando diventano parte del toolchain quotidiano. L’adozione sensata passa quindi da controlli: code review, test, policy di merge, e soprattutto ownership chiara su ciò che entra in produzione.

La traiettoria più credibile è che Claude Code Security e strumenti analoghi diventino una difesa aggiuntiva: un livello che anticipa problemi, accelera remediation e riduce il backlog di vulnerabilità note, soprattutto quelle ripetitive e pattern-based. È la posizione espressa anche da chi lavora sulla supply chain: qualsiasi tecnologia che aiuti a scrivere codice più sicuro è positiva, ma resta solo un elemento dentro una strategia più ampia fatta di controlli, processi, telemetria e risposta agli incidenti

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/25/claude-code-security-crea-il-panico-ma-non-uccide-la-cyber/?utm_source=rss&utm_medium=rss&utm_campaign=claude-code-security-crea-il-panico-ma-non-uccide-la-cyber




Sandworm_Mode: il “worm” della supply chain NPM


Un attacco che riprende la logica Shai-Hulud, ma sposta l’asticella sul toolchain moderno

Una recente analisi dei  ricercatori di Socket, un’azienda specializzata in sicurezza informatica, ha svelato una nuova campagna d’attacco alla supply chain dello sviluppo software colpendo NPM, l’ecosistema dove risiedono migliaia di librerie Javascript largamente usate dai programmatori di tutto il mondo. L’attacco è stato descritto come Sandworm_Mode con capacità di propagazione “worm-like”, costruita per scalare velocemente sfruttando la fiducia dell’ecosistema JavaScript e le abitudini quotidiane degli sviluppatori. L’operazione è stata attribuita a un cluster di almeno 19 pacchetti malevoli pubblicati tramite due alias e progettati per ingannare tramite typosquatting, cioè con nomi “quasi identici” a utility note, tool crypto e perfino strumenti legati al coding assistito dall’AI.

Typosquatting su utility, crypto e AI coding: l’innesco che porta il malware in pipeline

Il meccanismo d’ingresso è semplice e pericolosamente efficace: pacchetti che si presentano come dipendenze plausibili per attività comuni (sviluppo, parsing, compatibilità, tool “di supporto”) e che, una volta installati o richiamati, avviano una catena di esecuzione malevola. Le fonti convergono sul fatto che i pacchetti sono stati rimossi dal registry, ma il rischio resta per chi li abbia già introdotti nelle build locali o CI (continuous Integration)/CD (Contiuous Delivery), dove l’automazione moltiplica l’impatto.

Il salto di qualità rispetto al classico malware da pacchetto è nella propagazione: Sandworm_Mode abusa di credenziali NPM e GitHub sottratte per muoversi lateralmente e affianca questo canale a una GitHub Action manipolata che punta a raccogliere ed esfiltrare segreti di CI. Il modello, descritto come affine alla precedente ondata “Shai-Hulud”, consente non solo di colpire la singola workstation dello sviluppatore, ma di trasformare repository e pipeline in moltiplicatori di compromissione.

Un dettaglio particolarmente insidioso è la possibilità di usare pacchetti “vettore” per innescare workflow via GitHub Actions: basta aggiungere una dipendenza che attiva un percorso di pull request e workflow per arrivare ai segreti del repository e provare a iniettare ulteriori dipendenze o automatismi. È una dinamica che rende più difficile distinguere l’attacco da attività legittime, soprattutto in progetti molto attivi e con automazioni estese.

L’AI come nuova superficie d’attacco: iniezione di un server MCP “rogue” e prompt injection

La parte più attuale della campagna è l’aggancio agli assistenti di coding. Le analisi riportano che il malware installa un server MCP locale malevolo e lo registra nelle configurazioni di più strumenti, puntando a piattaforme come Claude Code, Cursor, Continue e Windsurf. L’idea è avvelenare l’interfaccia “fidata” tra sviluppatore e AI: tramite prompt injection, l’assistente viene indotto a leggere e consegnare informazioni sensibili (chiavi SSH, credenziali cloud, token NPM e segreti vari) verso il canale controllato dall’attaccante.

Non si parla solo di credenziali “classiche”. Sandworm_Mode mira esplicitamente anche alle API key dei provider LLM, oltre a environment variables e file .env, con logiche di validazione per capire cosa valga la pena monetizzare o riutilizzare. In parallelo, viene descritto un harvesting più profondo che include anche dati provenienti da password manager, a conferma della volontà di massimizzare l’accesso persistente agli ambienti di sviluppo.

Offuscamento assistito da Ollama: quando la “difesa” diventa mimetismo del payload

Un altro elemento interessante è l’uso di tooling locale per rendere il codice meno leggibile: il malware invoca un’istanza locale di Ollama per riscrivere porzioni del codice, cambiare nomi di variabili, alterare flussi di controllo, inserire delle esche e codificare stringhe. Non è “AI magica”, ma è un modo pragmatico per aumentare l’attrito per chi analizza e per le difese basate su firme, sfruttando risorse già presenti su molte workstation moderne.

Secondo Socket, la campagna adotta una strategia a due tempi: prima parte immediata e incondizionata dedicata alle operazioni più “profittevoli” (come il furto di chiavi legate al mondo crypto), seguita da attività più rumorose e “lunghe” come persistenza, propagazione e raccolta estesa di segreti. La razionalità è chiara: colpire subito, poi ridurre la probabilità di essere intercettati da sandbox o analisi “mordi e fuggi” tipiche delle prime ore.

Le analisi citano anche una capacità di dead switch configurabile ma inattiva, pensata per arrivare a una cancellazione della home directory nel caso in cui il malware perda accesso o non riesca più a operare con gli account compromessi. Anche se disabilitata nei campioni analizzati, la sola presenza del meccanismo segnala una postura offensiva pronta a passare dalla monetizzazione alla distruzione, se necessario.

Cosa fare ora: bonifica, rotazione credenziali e caccia ai workflow sospetti

La remediation non è “disinstallare e basta”. Chiunque sospetti l’installazione di uno dei pacchetti deve considerare compromessi token e segreti, perché l’attacco è costruito per muoversi tra macchina locale e CI. La linea operativa indicata dalle fonti è rimuovere i pacchetti malevoli eventualmente presenti, verificare modifiche recenti a file JSON e configurazioni, ruotare credenziali GitHub e NPM, ruotare i segreti di pipeline, e cercare workflow inattesi o recentemente introdotti nei repository. In parallelo, ha senso controllare configurazioni e integrazioni degli assistenti AI, perché il vettore MCP/prompt injection punta proprio a persistere nel toolchain.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/24/sandworm_mode-il-worm-della-supply-chain-npm/?utm_source=rss&utm_medium=rss&utm_campaign=sandworm_mode-il-worm-della-supply-chain-npm




Ring: una taglia a 4 zeri per forzare l’esecuzione in locale


Per chi vuole spezzare il legame tra le videocamere Ring e i server di Amazon, ora c’è un incentivo economico concreto: una taglia da 10.000 dollari per trovare un modo di far girare il sistema in locale e inviare lo streaming solo verso i computer del proprietario, senza che i flussi video o la telemetria finiscano nel cloud. L’iniziativa arriva nel pieno della polemica innescata dallo spot del Super Bowl e dalle discussioni sulla funzione “Search Party”, percepita da una parte dell’opinione pubblica come l’ennesimo passo verso un modello di sorveglianza “di quartiere” basato su AI.

La taglia della Fulu Foundation e l’obiettivo “subscription-busting”

L’iniziativa di “bug-bounty” è stata lanciata dalla Fulu Foundation, organizzazione non profit che dichiara di voler aumentare la consapevolezza sul tema della “tech ownership”, cioè il fatto che molti utenti, pur comprando l’hardware, restino dipendenti da firmware, back-end e abbonamenti imposti dal vendor. La fondazione mette sul tavolo 10.000 dollari iniziali e promette di eguagliare le donazioni della community fino a ulteriori 10.000 dollari.

Non basta una vulnerabilità qualunque, però: serve un percorso pratico per “staccare” Ring dal cloud

Il punto centrale è che non basta segnalare una vulnerabilità generica. La submission vincente dovrà dimostrare un metodo per far funzionare una Ring camera/doorbell in locale, mantenendo l’operatività e bloccando il traffico verso l’infrastruttura cloud di Amazon. L’idea, spiegata dalla fondazione, è consentire ai proprietari di scegliere se instradare i flussi su un proprio PC o server domestico, senza dipendere dal back-end per funzioni avanzate.

Lo sfondo: “Search Party”, backlash e timori da sorveglianza diffusa

Il lancio della bounty è una reazione alle critiche suscitate dallo spot di Ring mostrato durante il Super Bowl dove si promuoveva “Search Party” come strumento per ritrovare animali smarriti. Il timore, sollevato da più parti, è che l’uso di AI su una rete capillare di videocamere di quartiere possa spostare l’equilibrio tra sicurezza e privacy, anche al netto delle rassicurazioni pubbliche del vendor.

La Fulu Foundation motiva l’iniziativa anche richiamando i trascorsi di Ring sul fronte privacy. In particolare, la Federal Trade Commission statunitense ha annunciato rimborsi per oltre 5,6 milioni di dollari collegati a un accordo del 2023, citando contestazioni su accessi impropri a video dei clienti e carenze di protezione che avrebbero esposto account, camere e contenuti. In un ecosistema di sorveglianza domestica, la fiducia nel fornitore è un requisito di sicurezza, non solo un tema di reputazione.

Il modello di business: live view sì, ma registrazione e “plus” restano nel perimetro paywall

Sul piano pratico, la discussione si intreccia con la monetizzazione. Ring consente l’uso base dell’hardware (live view, motion alert, two-way talk), ma registrazione e funzioni avanzate restano legate al pagamento di un’abbonamento. È esattamente qui che la bounty vuole colpire: creare un’opzione che permetta di sfruttare l’hardware senza essere “obbligati” a un percorso cloud-first.

Sezione 1201 del DMCA: il vero muro non è tecnico, è legale

La parte più delicata è che l’operazione non è solo ingegneria inversa: entra in gioco la Sezione 1201 del DMCA che negli Stati Uniti limita la circonvenzione di “misure tecnologiche di protezione” e, di conseguenza, può rendere rischiosa la pubblicazione o distribuzione di strumenti e metodi di bypass. Esistono esenzioni periodiche gestite dal Copyright Office, ma il punto della fondazione è che l’attuale impianto normativo non facilita interventi che “rompono” i vincoli di ecosistema o abbonamento

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/23/ring-una-taglia-a-4-zeri-per-forzare-lesecuzione-in-locale/?utm_source=rss&utm_medium=rss&utm_campaign=ring-una-taglia-a-4-zeri-per-forzare-lesecuzione-in-locale




Finanza nel mirino, incidenti raddoppiati nel 2025


Il settore finanziario sta vivendo una fase di forte pressione: secondo la ricerca Exposure Management Research di Check Point, nel 2025 gli incidenti informatici a livello globale che hanno colpito banche e servizi finanziari sono più che raddoppiati rispetto al 2024, passando da 864 a 1.858 casi, con un incremento del 114,8%.

Europa: DDoS in prima linea e supply chain sotto pressione

Nel perimetro europeo, lo scenario evidenziato dalla ricerca mostra una forte concentrazione di attività DDoS diretta contro portali finanziari, sistemi di pagamento e servizi esposti al pubblico. A questa ondata si affiancano dinamiche tipiche dell’ecosistema ransomware contemporaneo, dove la supply chain diventa un moltiplicatore d’impatto e consente di scalare rapidamente su più obiettivi, soprattutto in contesti interconnessi come quelli dell’UE.

Il report attribuisce un ruolo centrale anche alle superfici d’attacco “moderne”: cloud e SaaS. Le configurazioni errate e la governance insufficiente dell’identità vengono indicate come fattori ricorrenti dietro violazioni e fughe di dati, con una crescita coerente con campagne a matrice geopolitica e hacktivista che, nel continente, trovano spesso terreno fertile quando i servizi digitali sono ad alta visibilità.

Italia tra i Paesi colpiti: pressione combinata e attacchi multi-vettore

Nel ranking europeo dei Paesi maggiormente colpiti, l’Italia risulta settima con 14 attacchi, dietro Regno Unito (61), Francia (47), Germania (42), Spagna (30), Polonia e Finlandia (20). Il dato va letto come indicatore di esposizione, non come misura “assoluta” di sicurezza, perché la pressione si distribuisce in modo non uniforme a seconda del peso dei sistemi finanziari nazionali, della loro digitalizzazione e della loro visibilità nel contesto geopolitico.

A livello europeo, nel 2025 sono stati conteggiati 74 incidenti ransomware nel settore finanziario, 47 episodi di defacement – spesso legati a tensioni geopolitiche e hacktiviste – e 43 violazioni o fughe di dati. La combinazione di disruption, estorsione e data exposure descrive un rischio “sistemico” che colpisce la continuità operativa e, contemporaneamente, la fiducia dei clienti e l’aderenza regolatoria.

DDoS: da estorsione a strumento di pressione ideologica

Il report indica gli attacchi DDoS come la minaccia più dirompente del 2025: i casi globali passano da 329 a 674, con un incremento del 105%. La novità è la motivazione che non è più solo economica: in molti casi l’obiettivo è negare l’accesso ai cittadini e generare impatto mediatico, colpendo portali bancari, interfacce di pagamento e fornitori di servizi finanziari.

Dal punto di vista operativo, emerge un pattern: campagne rapide, ad alto volume, ripetute, spesso concentrate in finestre temporali brevi ma con frequenza tale da trasformare l’interruzione “spot” in una pressione continua. Questo tipo di stress mette in crisi non solo la capacità di assorbimento della banda, ma anche i processi di risposta e la gestione della comunicazione verso clienti e stakeholder.

Un elemento rilevante è la “centralizzazione” dei gruppi che rivendicano gli attacchi: una porzione importante degli eventi osservati viene attribuita a pochi operatori molto attivi, come Keymous+ (121 attacchi) e NoName057 (98 attacchi). Il modello è tipico dell’hacktivism contemporaneo, che fa leva su botnet facilmente reperibili e su infrastrutture condivise, abbassando la soglia tecnica necessaria per generare impatto.

Sul piano difensivo, il comunicato sottolinea implicitamente un limite: lo scrubbing “on demand” tende a non bastare quando gli attacchi diventano persistenti e multi-ondata. In scenari di questo tipo, la resilienza richiede monitoraggio continuo, architetture di mitigazione sempre attive e strategie di routing capaci di sostenere stress prolungati.

Data breach e leak: l’ombra lunga degli errori nella configurazione di identity e cloud

Le violazioni e fughe di dati salgono da 256 a 443 incidenti globali (+73%). Qui l’impatto è meno “visibile” nell’immediato rispetto ai DDoS, ma spesso più corrosivo: accessi di lunga durata, esfiltrazione silenziosa e disclosure ritardata sono coerenti con campagne furtive che mirano a monetizzare dati o a costruire leve di ricatto e influenza.

Gli Stati Uniti restano l’area più colpita con 177 casi, pari al 40% del totale globale, mentre India e Indonesia vengono indicate come nuovi hotspot. La lettura tecnica è legata alla crescita rapida di ecosistemi finanziari cloud-centrici, dove l’aumento dei volumi di transazioni digitali e l’estensione delle integrazioni con terze parti ampliano la superficie d’attacco e il valore dei dati disponibili.

Attribuzione più difficile: 33% di incidenti senza un responsabile identificato

Un dato che merita attenzione è che il 33% degli incidenti di data breach viene attribuito ad attori sconosciuti. Non è un vuoto statistico: è un segnale di maturità offensiva, con maggiore sicurezza operativa, infrastrutture effimere, identità decentralizzate e account temporanei che rendono più complessa l’attribuzione, soprattutto quando le tracce vengono “sporcate” tra deep e dark web.

Restano attivi anche gruppi specializzati in compromissione e monetizzazione dei dati, descritti come capaci di sfruttare errori di configurazione, acquistare accessi iniziali e usare credenziali in vendita per alimentare estorsioni. La persistenza di bucket aperti, controlli permissivi e API non monitorate viene indicata come sintomo di una governance dell’accesso ancora insufficiente, nonostante gli investimenti.

Ransomware: 451 casi e multi-estorsione come standard operativo

Nel 2025 gli incidenti ransomware rilevati da Check Point nel settore finanziario sono stati 451, in crescita rispetto ai 269 del 2024. Il report lega l’aumento alla maturità del ransomware-as-a-service e all’evoluzione dell’estorsione: non più solo cifratura, ma esfiltrazione, pressione reputazionale e targeting di figure apicali. La posta in gioco cresce perché gli istituti finanziari hanno una bassa tolleranza al downtime e dipendono da catene di servizi interconnessi.

Gli Stati Uniti guidano anche qui con 196 casi (43,5%), seguiti da Corea del Sud (31), Regno Unito (22) e Canada (16). La distribuzione riflette dove il digital banking è più denso e quindi più “monetizzabile”, perché l’attaccante può massimizzare l’effetto leva su servizi essenziali e su basi clienti ampie.

Pochi gruppi, grande impatto: affiliazioni e toolchain condivise

Il comunicato evidenzia una forte concentrazione anche sul fronte ransomware: Qilin guida con 83 incidenti (18,4%), seguito da Akira (37) e Clop (19). Il modello “a programma di affiliazione” rende l’ecosistema resiliente e scalabile, con malware modulari, toolchain condivise e attori che sfruttano vulnerabilità VPN, credenziali rubate e fornitori terzi come punto d’ingresso per colpire più vittime.

Con la multi-estorsione, le contromisure classiche non bastano più: backup e ripristino restano essenziali, ma non eliminano il rischio di esposizione, sanzioni regolatorie e danno reputazionale quando i dati sono già usciti o quando l’attaccante “sposta” la pressione su clienti e management.

Verso il 2026: difesa sempre attiva e intelligence condivisa

Nel passaggio al 2026, Check Point sottolinea la necessità di rafforzare la preparazione agli attacchi DDoS e migliorare la condivisione transfrontaliera delle informazioni sulle minacce. La richiesta è di aumentare la consapevolezza situazionale in tempo reale, unificando threat intelligence, insight dal dark web, analisi delle vulnerabilità e alzando il livello su cloud posture e identity governance, perché gli avversari continuano a sfruttare le fragilità dei sistemi interconnessi europei.

Il messaggio di fondo è che la finanza è entrata in una fase in cui disruption ideologica, compromissione furtiva e estorsione industrializzata convivono. E dove la resilienza non può più essere un insieme di controlli isolati, ma un modello continuo, “always on”, capace di leggere il contesto e anticipare le campagne prima che arrivino sui servizi critici.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/20/finanza-nel-mirino-incidenti-raddoppiati-nel-2025/?utm_source=rss&utm_medium=rss&utm_campaign=finanza-nel-mirino-incidenti-raddoppiati-nel-2025




Davvero si può fare “jailbreak” a un caccia F-35?


Durante un’intervista in un podcast, il segretario di Stato olandese alla Difesa Gijs Tuinman ha sostenuto che un F-35 potrebbe essere “jailbreakato” “proprio come un iPhone”, nel contesto di una domanda molto concreta: cosa accadrebbe se, per ragioni politiche o strategiche, gli Stati Uniti smettessero di fornire supporto e aggiornamenti software agli alleati europei. Il punto non è la battuta ad effetto, ma il tema che porta con sé: il controllo del software come leva di potere operativo.

Tuinman ha continuato ricordando che l’F-35 è un programma multinazionale, con contributi industriali significativi anche fuori dagli USA, e che questa interdipendenza rende il velivolo, a suo dire, un “prodotto condiviso”. La realtà però è che, anche in un ecosistema cooperativo, l’accesso ai livelli più sensibili del software e della catena di aggiornamento resta storicamente fortemente centralizzato.

Che cosa significa davvero “jailbreak” su un sistema d’arma
Solitamente, quando parliamo di “jailbreak” ci si riferisce alla rimozione di vincoli imposti da un vendor per installare software non autorizzato o accedere ad aree riservate di un prodotto. Trasportare questa idea su un caccia di quinta generazione è tecnicamente e operativamente più complesso: non si parla solo di “installare un’app”, ma di intervenire su architetture critiche, catene di firme, procedure di validazione, sicurezza funzionale e requisiti di certificazione. Per questo diversi commentatori hanno letto la frase come una provocazione politica o un messaggio negoziale più che come un’indicazione tecnica.

Perché non è un iPhone: barriere di accesso e ricerca quasi impossibili
Un elemento sottolineato da chi fa penetration test in ambito aeronautico è la differenza strutturale tra hardware consumer e piattaforme militari. La comunità di ricerca che “stressa” i dispositivi di massa non esiste, di fatto, per i caccia: l’accesso fisico è rarissimo, rigidamente controllato e i vincoli di sicurezza e segretezza rendono improbabile che eventuali tecniche diventino pubbliche. In altre parole, anche se vulnerabilità o percorsi di aggiramento esistessero, sarebbe molto meno probabile che emergano come avviene nel mondo smartphone.

Sovranità operativa vs sicurezza: una tensione inevitabile
La discussione si intreccia con il modo in cui l’F-35 è stato gestito nel tempo: aggiornamenti, manutenzione e supporto sono stati storicamente orchestrati tramite sistemi di gestione della flotta e della logistica come ALIS (Autonomic Logistics Information System), citato anche nel dibattito mediatico che ha seguito le parole di Tuinman. Qui la posta in gioco non è solo la “patch”, ma l’intero ciclo di vita digitale del velivolo: configurazioni, diagnostica, documentazione tecnica, pacchetti di aggiornamento e dipendenze di supply chain.

Qualsiasi apertura al “software terzo” su piattaforme militari entra in collisione con esigenze opposte: da una parte la sovranità e la continuità operativa, dall’altra la riduzione del rischio di compromissione e di interferenze non autorizzate. Più autonomia per l’operatore significa anche più superficie di responsabilità: integrazioni, update e hardening diventano un problema locale, non più delegabile al prime contractor. Ed è esattamente qui che il tema “jailbreak” diventa delicato: l’autonomia tecnica può essere desiderabile in scenari geopolitici instabili, ma aumenta l’esposizione se governance, sicurezza e assurance non sono allo stesso livello.

Il precedente che tutti citano: l’eccezione israeliana
Nel dibattito torna spesso Israele, indicato come l’unico Paese ad aver negoziato margini più ampi per integrare componenti e software nazionali sulla propria variante, l’F-35I “Adir”. Le fonti descrivono questa eccezione come un equilibrio tra esigenze di personalizzazione e limiti imposti per non toccare i “cuori” più sensibili del sistema. È un precedente importante perché dimostra che spazi di autonomia possono esistere, ma come eccezione negoziata, non come default per tutti gli operatori.

Il fantasma del “kill switch” e l’effetto sulla fiducia europea
Le parole di Tuinman arrivano in un clima già carico: negli ultimi mesi/anni, a ondate, in Europa sono riemerse paure legate alla possibilità che gli USA possano limitare capacità, supporto o aggiornamenti dei sistemi avanzati venduti agli alleati. Al di là della verifica tecnica di un “interruttore remoto”, la questione cruciale è la fiducia: quanto controllo accetti di cedere quando compri una piattaforma definita dal software?

La notizia è meno relegata al mondo della difesa e dell’aviazione di quanto non sembri. L’F-35 è l’esempio estremo di una tendenza generale: prodotti sempre più complessi, vincolati a ecosistemi di aggiornamento, telemetria, autenticazione e supply chain, dove il confine tra manutenzione, sicurezza e controllo industriale si assottiglia. La provocazione del “jailbreak” rende evidente che, anche nel mondo difesa, la domanda sta cambiando: non è più solo “quanto è avanzato l’hardware”, ma chi governa il software, per quanto tempo e a quali condizioni geopolitiche.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/18/davvero-si-puo-fare-jailbreak-a-un-caccia-f-35/?utm_source=rss&utm_medium=rss&utm_campaign=davvero-si-puo-fare-jailbreak-a-un-caccia-f-35




Il malware che ruba password e ambienti delle IA locali


Hudson Rock è un’azienda specializzata in sicurezza informatica che si è imbattuta (probabilmente) per prima in un’interessante evoluzione nel mondo degli infostealer. Per la prima volta, infatti, è stato trovato un malware che prende di mira non soltanto l’identità “umana”, ma anche l’identità operativa di un assistente software. Il payload, infatti, ha esfiltrato l’intero ambiente di configurazione di OpenClaw (ex – Clawdbot e Moltbot), cioè la “memoria” e i parametri che definiscono come un agente AI lavora e si comporta.

Alon Gal, CTO di Hudson Rock, ha ricondotto l’infezione a una probabile variante di Vidar, un infostealer attivo dal 2018, sottolineando però che l’acquisizione dei file non sarebbe avvenuta tramite un modulo dedicato a OpenClaw. Il punto, in questa storia, è proprio che la sottrazione del materiale sensibile è stata ottenuta con un approccio più grezzo ma efficace: una routine di raccolta file generalista, capace di pescare directory e formati “interessanti” e di trasformare un furto di segreti standard in un furto della “personalità” digitale di un agente.

Un twist interessante perché, alla fine, l’AI è un “rapimento collaterale”

Dal punto di vista tecnico, il caso diventa rilevante perché mostra quanto sia facile, per un infostealer tradizionale, intercettare dati ad alto valore senza conoscere nel dettaglio la piattaforma. La routine di file-grabbing avrebbe raccolto openclaw.json, un file che include il gateway token e metadati come email di riferimento e percorso del workspace, aprendo la strada all’abuso dell’autenticazione verso il gateway. Nello stesso set compaiono device.json, che contiene chiavi crittografiche usate per pairing sicuro e operazioni di firma, e soul.md, un documento che descrive principi operativi, linee comportamentali e limiti etici dell’agente ovvero il perimetro entro cui il sistema prende decisioni e agisce. La sottrazione del gateway token è la leva più immediata: se la porta dell’istanza locale è esposta, un attaccante può connettersi da remoto all’OpenClaw della vittima, oppure mascherarsi come client legittimo nelle richieste autenticate verso l’AI gateway. In pratica, si passa dal furto di password al furto di “autorità”: se l’agente ha accesso a email, API, cloud e risorse interne, l’attaccante ottiene un canale già autorizzato ad agire, spesso con privilegi che superano quelli di un singolo account umano.

Le contromisure sono ancora “crude”

Il contesto che circonda OpenClaw rende questa dinamica ancora più delicata, perché la superficie d’attacco non è solo endpoint e configurazione, ma anche ecosistema e supply chain di “skill AI”. I maintainers hanno annunciato iniziative come la collaborazione con VirusTotal per esaminare skill potenzialmente malevole caricate su ClawHub, definire un threat model e introdurre audit per intercettare configurazioni errate, segno che la piattaforma sta entrando nella fase in cui la sicurezza deve diventare un requisito strutturale. Nel frattempo, ricerche indipendenti descrivono campagne che sfruttano skill come esche e spostano il payload su siti lookalike, con l’obiettivo di bypassare i controlli e trasformare i registri di skill in vettori di attacco a catena. A questo si aggiungono criticità di governance dei dati, come il problema evidenziato su Moltbook, dove un account agente non risulterebbe eliminabile, lasciando gli utenti senza un meccanismo pratico per rimuovere identità e contenuti associati. E soprattutto pesa il tema dell’esposizione: analisi threat intelligence hanno indicato la presenza di centinaia di migliaia di istanze OpenClaw esposte che in presenza di vulnerabilità possono diventare un trampolino verso scenari di remote code execution.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/17/il-malware-che-ruba-password-e-ambienti-delle-ia-locali/?utm_source=rss&utm_medium=rss&utm_campaign=il-malware-che-ruba-password-e-ambienti-delle-ia-locali




Lo shotdown USA tarpa le ali alla CISA


Il blocco delle attività del Department of Homeland Security scattato alle 00:01 del 14 febbraio 2026 non spegne CISA, ma la costringe a lavorare con un organico drasticamente ridotto.

In pratica l’agenzia resta in piedi solo per le funzioni considerate “essenziali” dall’Antideficiency Act, con 888 persone attive su 2.341, circa il 38% della forza lavoro. Il risultato è un paradosso operativo: la cybersecurity federale continua, ma con capacità e velocità inevitabilmente inferiori, mentre l’esposizione a campagne ransomware e sfruttamento massivo di vulnerabilità rimane costante.

Il vincolo legale non riguarda la possibilità materiale di lavorare, bensì il fatto che, senza stanziamenti del Congresso, i dipendenti non possano essere retribuiti e l’agenzia non possa avviare o proseguire attività non “eccezionali”. In termini concreti, molti lavoratori vengono messi in congedo forzato, mentre una quota rimane operativa (senza paga) nelle aree ritenute indispensabili a proteggere vita umana, proprietà e sicurezza nazionale. Questo meccanismo crea una tensione strutturale: la risposta agli incidenti resta formalmente possibile, ma la resilienza dipende da un perimetro di attività ristretto e da persone che devono garantire continuità in condizioni anomale.

La “collateral damage zone”: perché CISA paga il prezzo della politica

Nel racconto di queste ore, CISA finisce nel ruolo di danno collaterale. Alcune componenti del DHS restano di fatto meno coplpite dalla chiusura, mentre CISA deve selezionare cosa mantenere acceso e cosa rinviare. La conseguenza per chi fa sicurezza è immediata: meno team disponibili, meno progetti nuovi, più triage e più rinunce. E quando la gestione si sposta dalla pianificazione alla sopravvivenza operativa, il rischio più concreto non è solo “fare meno”, ma fare più lentamente ciò che conta di più.

Il testo chiarisce che i dipendenti mandati a casa possono essere richiamati se emerge un’esigenza riconducibile alle eccezioni previste: incidenti con impatto su infrastrutture critiche, minacce su larga scala, sfruttamento esteso di una falla capace di colpire sistemi strategici. L’esempio implicito è quello di eventi “sistemici”, come campagne ransomware su settori vitali o ondate di exploitation comparabili a quanto visto con log4j. In pratica, però, questi richiami sarebbero probabilmente chirurgici: verrebbero riattivati solo i gruppi con competenze specifiche sullo scenario in corso e anche loro opererebbero senza retribuzione.

KEV Catalog: luce accesa, ma con meno “bulbi” operativi

Tra i servizi destinati a rimanere in vita c’è il Known Exploited Vulnerabilities Catalog, diventato negli anni una sorgente di riferimento non solo per le agenzie federali, ma anche per SOC e vulnerability management di mezzo mondo. La parte cruciale è che il catalogo resta online e, se compare una vulnerabilità attivamente sfruttata con potenziale impatto su vita, proprietà o sicurezza nazionale, l’aggiornamento rientra con buona probabilità nel perimetro “eccezionale”. Il funzionamento del KEV soffre particolarmente questa situazione perché dietro una nuova voce nel catalogo non c’è un semplice copia-incolla di un CVE. Serve verificare lo sfruttamento, comprendere il contesto d’attacco, valutare disponibilità e qualità della patch o delle mitigazioni, coordinarsi con agenzie e stakeholder. Con una forza lavoro ridotta, la priorità tenderà a spostarsi verso gli eventi più urgenti e con exploitation in corso. Questo implica un effetto collaterale importante: l’inserimento o il “recall” di vulnerabilità più datate, pur sfruttate in passato o riemerse in nuove catene d’attacco, rischia di slittare. Per chi gestisce remediation a livello enterprise, la conseguenza è pratica: il segnale KEV potrebbe arrivare più tardi e quindi più tardi potrebbero allinearsi patching e compensating controls.

Inoltre, un conto è tenere disponibile il catalogo, un altro è far sì che chi è obbligato ad adeguarsi lo faccia davvero. Il testo suggerisce che le attività di enforcement e di “sollecito” sulla conformità potrebbero non rientrare tra le operazioni che continueranno a funzionare. In uno scenario del genere, la pressione organizzativa sulle realtà soggette agli obblighi si indebolisce e la compliance rischia di diventare più “volontaria” che guidata. Dal punto di vista della postura di sicurezza, è un passaggio delicato: il valore del KEV non è solo informativo, ma anche disciplinare perché impone priorità e tempi. Se la sorveglianza si attenua, cresce il rischio di backlog e di esposizione prolungata.

Non è “solo pubblico”: perché il settore privato globale deve ascoltare

È vero che la missione primaria di CISA è innalzare il livello di sicurezza delle agenzie federali e, per estensione, dell’ecosistema critico. Ma oggi KEV viene usato come strumento quotidiano da team di sicurezza ovunque, perché offre un criterio pragmatico: “questa vulnerabilità è sfruttata davvero, quindi va trattata come prioritaria”. Anche con l’agenzia in modalità ridotta, il KEV resta un riferimento globale e continuerà a influenzare triage, patch windows, decisioni di compensazione e metriche di esposizione. Il problema è la latenza: se l’informazione arriva più tardi, le aziende potrebbero scoprire più tardi che stanno inseguendo un rischio già diventato attivo.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/16/lo-shotdown-usa-tarpa-le-ali-alla-cisa/?utm_source=rss&utm_medium=rss&utm_campaign=lo-shotdown-usa-tarpa-le-ali-alla-cisa




False estensioni AI su Chrome: rubano API e sessioni


Un’inquietante campagna di cyberspionaggio ha colpito almeno 260.000 utenti Chrome, sfruttando il crescente interesse verso gli assistenti basati su intelligenza artificiale. Dietro un’apparente offerta di tool utili per scrivere, riassumere o leggere le email, si celano invece estensioni malevole progettate per rubare dati sensibili e informazioni personali.

AiFrame: l’infrastruttura della truffa

L’indagine è stata condotta da LayerX Security che ha ribattezzato l’operazione con il nome “AiFrame”. Tutte le estensioni riconosciute all’interno di questa campagna malevola, ben 32, condividono lo stesso codice base e comunicano con domini remoti sotto il controllo di tapnetic[.]pro, un’infrastruttura centralizzata che consente agli attaccanti di gestire in tempo reale i payload e le capacità delle estensioni.

Spesso, queste campagne durano poco dal momento che le estensioni vengono controllate spesso dagli esperti di sicurezza, ma AiFrame ha organizzato un sistema di “reincarnazione” automatica grazie al quale diverse estensioni rimosse dallo store ufficiale sono ricomparse con nuovi ID, mantenendo nome e funzionalità simili. È il caso di AI Sidebar, che dopo essere stata rimossa come “Gemini AI Sidebar” (con 80.000 installazioni) è riapparsa con un nuovo ID, già utilizzato da oltre 70.000 utenti.

Iframe invisibili e attacchi silenziosi

Uno degli elementi tecnici più pericolosi di AiFrame è l’uso degli iframe. L’interfaccia dell’estensione non è reale, ma è un overlay caricato da remoto che può essere modificato dinamicamente in ogni momento, senza passare da un aggiornamento ufficiale sul Chrome Web Store. Questo iframe è in grado di inviare comandi all’estensione, istruendola a leggere contenuti dalla pagina attiva.

Gli script iniettati sfruttano librerie come Readability di Mozilla per estrarre titoli, testi, metadata e contenuti leggibili. Le informazioni raccolte, inclusi eventuali token di autenticazione e contenuti dinamici, vengono poi trasmesse al dominio remoto, sfuggendo a ogni controllo dell’utente e di Google.

Gmail nel mirino: accesso completo ai contenuti

Circa la metà delle estensioni individuate si concentra su Gmail, implementando un codice comune per l’integrazione con la casella di posta. L’estensione è in grado di leggere i messaggi visibili, accedere ai contenuti delle conversazioni, e persino intercettare i testi in fase di scrittura. Tutti questi dati vengono silenziosamente inoltrati ai server remoti, senza che l’utente possa rendersene conto.

Il badge “Featured” assegnato ad alcune di queste estensioni, come nel caso di “AI Assistant”, aggrava ulteriormente la situazione: l’etichetta di qualità contribuisce a consolidare un falso senso di sicurezza, inducendo l’utente a fidarsi di un componente che, in realtà, agisce da agente malevolo nel browser.

L’ingegneria sociale dell’intelligenza artificiale

L’attacco è particolarmente insidioso perché sfrutta un fenomeno sociotecnico recente: l’interazione conversazionale con gli assistenti AI ha abbattuto le barriere di diffidenza, portando gli utenti a condividere più facilmente dati e contesti personali. Questa abitudine è stata trasformata dagli attaccanti in un punto di forza: gli iframe truccati simulano perfettamente le interfacce di strumenti noti come ChatGPT, Claude o Gemini, rendendo l’intercettazione praticamente invisibile.

Anche il riconoscimento vocale è stato utilizzato come vettore: alcune estensioni captano le parole pronunciate dagli utenti, le trascrivono e le inviano al server controllato dagli attaccanti, aggiungendo un ulteriore livello di sorveglianza invisibile.

Ancora disponibili, ancora pericolose

Nonostante la gravità della scoperta, molte delle estensioni malevole risultano ancora oggi disponibili sul Chrome Web Store. Google, al momento della pubblicazione del report, non ha rilasciato alcun commento ufficiale sulla vicenda.

Il report completo di LayerX elenca gli ID di tutte le estensioni coinvolte. Finché non verranno rimosse, il consiglio è di sospendere ogni fiducia verso gli assistenti AI installabili come estensioni browser, almeno fino a una verifica rigorosa delle fonti e dei permessi richiesti.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/13/false-estensioni-ai-su-chrome-rubano-api-e-sessioni/?utm_source=rss&utm_medium=rss&utm_campaign=false-estensioni-ai-su-chrome-rubano-api-e-sessioni




Effetto Domino: nel 2026 i fornitori sono le vulnerabilità più critiche


Nell’ultimo High-Tech Crime Trends Report 2026 realizzato da Group-IB, leader globale nella cybersecurity e nell’investigazione dei crimini digitali, emerge un quadro inquietante sull’evoluzione delle minacce. Lo studio, frutto di un monitoraggio costante effettuato dai centri DCRC in 11 paesi e basato su telemetria e investigazioni sul campo, è stato concepito per fornire a governi e aziende una utile guida per anticipare i rischi di un panorama cyber sempre più interconnesso.

L’industrializzazione del rischio nella supply chain moderna

Da qualche tempo, ormai, l’attenzione dei gruppi dediti al cybercrimine si sta spostando dalle singole infrastrutture verso l’intero ecosistema di fiducia che lega fornitori e clienti finali. Secondo l’analisi di Group-IB, non siamo più di fronte a intrusioni isolate ma a una vera e propria compromissione sistemica delle catene di approvvigionamento tecnologico globale. Gli attaccanti hanno compreso che colpire un singolo vendor SaaS, un fornitore di servizi gestiti o un repository di codice significa ottenere un accesso immediato e persistente a centinaia di organizzazioni a valle della catena di distribuzione del servizio o del  software. Questo cambio di paradigma trasforma una singola vulnerabilità locale in un effetto domino capace di paralizzare interi settori industriali con un’efficienza operativa senza precedenti.

La militarizzazione del codice aperto e dei flussi d’identità

Uno dei fronti più critici evidenziati dal report riguarda la corruzione dei repository open-source come npm e PyPI, diventati i nuovi vettori per la distribuzione di malware su scala “industriale”. Attraverso il furto di credenziali dei manutentori e l’uso di worm automatizzati, i cybercriminali iniettano codice malevolo nelle librerie software, trasformando le pipeline di sviluppo in canali di infezione di massa. Parallelamente, assistiamo a un’evoluzione del phishing potenziato dall’intelligenza artificiale che ora mira specificamente ai workflow di integrazione OAuth. Questo approccio permette agli attori malevoli di aggirare l’autenticazione a più fattori e stabilire una presenza legittima e duratura all’interno degli ambienti cloud e dei sistemi CI/CD, rendendo la distinzione tra traffico lecito e malevolo quasi impossibile per i perimetri difensivi classici.

L’ecosistema del ransomware e il mercato degli accessi a monte

Il modello operativo del crimine informatico si è strutturato in una filiera altamente specializzata dove i broker di accesso iniziale e gli operatori ransomware collaborano con una precisione e un coordinamento degno delle migliori filiere produttive tradizionali. L’obiettivo primario dei gruppi di minaccia non è più la singola vittima, ma i punti di accesso a monte che garantiscono un’esposizione multi-tenant. Questo approccio moltiplica l’impatto finanziario delle campagne di estorsione, poiché la violazione di un unico fornitore di servizi si traduce nella compromissione simultanea di decine di database di clienti diversi. I gruppi più sofisticati, tra cui spiccano nomi come Lazarus e Scattered Spider, stanno sfruttando metodicamente queste architetture di fiducia condivisa per massimizzare l’asimmetria dell’attacco e minimizzare i tempi di rilevamento.

Verso una difesa basata sulla gestione della fiducia sistemica

In questo scenario di minacce interconnesse, la sicurezza informatica deve evolvere verso una protezione che non si limiti ai confini aziendali ma che analizzi ogni singola dipendenza e relazione digitale. Come sottolineato dai ricercatori di Group-IB, la sfida attuale per i responsabili della sicurezza è mettere in sicurezza la fiducia stessa attraverso un monitoraggio rigoroso delle integrazioni di terze parti e una verifica continua delle identità. Non è più sufficiente proteggere i propri asset isolati, poiché è necessario anticipare i rischi emergenti analizzando le dinamiche degli ecosistemi underground dove vengono scambiati gli accessi privilegiati. Solo una visione che integri l’intelligence predittiva con una comprensione profonda delle catene di attacco integrate può permettere alle aziende di interrompere il ciclo dell’offensiva prima che il danno diventi sistemico.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/12/effetto-domino-nel-2026-i-fornitori-sono-le-vulnerabilita-piu-critiche/?utm_source=rss&utm_medium=rss&utm_campaign=effetto-domino-nel-2026-i-fornitori-sono-le-vulnerabilita-piu-critiche




Lummastealer risorge dalle ceneri: ancora una volta lo stop è momentaneo


L’ecosistema del cybercrime dimostra ancora una volta una resilienza straordinaria: a meno di dodici mesi dall’operazione di smantellamento internazionale che sembrava averne decretato la fine, LummaStealer è riemerso con una catena di infezione profondamente rinnovata. Il ritorno di questo infostealer non è un semplice “rebranding”, ma una ristrutturazione tattica che vede l’introduzione di CastleLoader come primo stadio critico.

Questa nuova architettura dimostra come i gruppi MaaS (Malware-as-a-Service) siano in grado di riorganizzare le proprie infrastrutture C2 e i vettori di delivery in tempi record, capitalizzando sulle lezioni apprese dai precedenti shutdown delle autorità.

L’Architettura Modulare e il Ruolo di CastleLoader

La nuova struttura offensiva si basa su un design modulare a più stadi, dove CastleLoader funge da sofisticato “apripista” per il payload finale. Questo loader non è un semplice downloader, ma un componente progettato per l’evasione preventiva. Una volta eseguito, solitamente attraverso archivi compressi che simulano software legittimo, CastleLoader avvia una serie di controlli ambientali per rilevare la presenza di sandbox o debugger. Solo dopo aver confermato di trovarsi su un host reale e non in un ambiente di analisi, il loader stabilisce una connessione cifrata per recuperare LummaStealer, iniettandolo direttamente nella memoria di processi di sistema già attivi, minimizzando così l’impronta sul file system dell’host.

Il nucleo operativo di LummaStealer è caratterizzato da un offuscamento estremamente aggressivo, finalizzato a neutralizzare sia l’analisi statica che quella euristica. Il malware impiega tecniche di risoluzione dinamica delle funzioni API, evitando di importare palesemente le librerie sospette nella propria tabella di importazione (IAT). Questo approccio, unito all’uso di junk code e metamorfismo del codice sorgente, rende estremamente difficile la creazione di firme rilevanti. Inoltre, il malware sfrutta il controllo del flusso indiretto per confondere i motori di disassemblaggio, garantendo che l’esecuzione del codice malevolo avvenga in modo non lineare e protetto da trigger di rilevamento comportamentale.

Esfiltrazione Mirata e Gestione dei Dati Sensibili

Una volta stabilita la persistenza in memoria, LummaStealer attiva i suoi moduli di scansione focalizzati sull’estrazione di asset digitali di alto valore. Il targeting è chirurgico: il malware interroga i database SQL dei browser per recuperare cookie di sessione (utili per il session hijacking), dati di auto-fill e credenziali salvate. Particolare enfasi viene posta sui cold wallet di criptovalute e sulle estensioni browser dedicate alla gestione di asset digitali, dove il malware tenta di esfiltrare chiavi private e seed. I dati raccolti vengono pacchettizzati e inviati a server C2 attraverso protocolli di comunicazione che imitano il normale traffico web, spesso sfruttando servizi cloud legittimi come tunnel per mascherare la destinazione finale dei pacchetti esfiltrati.

Infrastruttura di Comando e Strategie di Hardening

La rete di Comando e Controllo (C2) è stata riprogettata per evitare i singoli punti di fallimento che hanno portato al precedente abbattimento. Gli operatori utilizzano ora un’architettura decentralizzata o domini a vita breve (fast-flux), che rendono complessa l’identificazione dei server master. Per i difensori IT, il contrasto a questa minaccia richiede un monitoraggio intensivo dei tentativi di iniezione di memoria e delle anomalie nel traffico di rete in uscita. È essenziale implementare soluzioni EDR capaci di correlare l’apertura di file sospetti con chiamate di sistema insolite, oltre a una rigorosa segmentazione dei privilegi utente per impedire che il loader possa scalare le autorizzazioni necessarie per l’esfiltrazione dei dati di sistema.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/11/lummastealer-risorge-dalle-ceneri-ancora-una-volta-lo-stop-e-momentaneo/?utm_source=rss&utm_medium=rss&utm_campaign=lummastealer-risorge-dalle-ceneri-ancora-una-volta-lo-stop-e-momentaneo