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

---

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

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

Un malware progettato per colpire gli sviluppatori

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

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

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

Il rischio supply chain continua a crescere

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

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

Esecuzione in memoria e capacità anti-detection

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

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

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

La doppia architettura rootkit

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

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

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

Le backdoor PAM e il furto di credenziali

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

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

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

Sei meccanismi di persistenza contemporanei in un framework offensivo completo

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

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

Linux sempre più nel mirino

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

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

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

---

---

---

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

Il modello Managed Detection and Response supera i limiti strutturali del SOC tradizionale. Con NovaMDR™, Sangfor Technologies e Forenova portano in Italia una soluzione che trasforma il dato grezzo in risposta operativa concreta, con copertura 24/7 e presidio umano qualificato.

Il problema non è più stabilire se un’azienda verrà attaccata, ma capire con quanta rapidità sarà in grado di accorgersene e reagire. Eppure, nella stragrande maggioranza delle organizzazioni italiane, soprattutto tra PMI e medie imprese, la distanza tra il momento in cui una minaccia si infiltra nella rete e quello in cui qualcuno se ne accorge è ancora drammaticamente ampia: ore, a volte giorni interi. Un lasso di tempo sufficiente affinché un ransomware cifri interi archivi oppure un attore malevolo esfiltri dati sensibili nel silenzio più totale.

Secondo il report IBM Cost of a Data Breach 2024, il tempo medio globale per identificare e contenere una violazione è di 258 giorni, in calo rispetto ai 277 dell’anno precedente, ma ancora un dato che descrive organizzazioni esposte per oltre otto mesi consecutivi prima di riuscire a contenere un incidente. Il costo medio per violazione ha raggiunto i 4,88 milioni di dollari, con un incremento del 10% rispetto al 2023 e il valore più alto mai registrato dal rapporto.

In Europa il quadro non è più rassicurante: secondo l’ENISA Threat Landscape 2024, il ransomware si conferma la seconda minaccia più diffusa nel panorama europeo, stabilizzata su livelli elevati nonostante le crescenti operazioni di contrasto delle autorità. Gli attacchi alla supply chain rappresentano un vettore trasversale in forte espansione, con le PMI sempre più nel mirino proprio perché percepite come anello debole delle catene di fornitura.

La risposta strutturale a questa fragilità si chiama MDR (Managed Detection and Response) e negli ultimi anni è diventata uno degli ambiti a maggiore crescita nell’intero panorama della cybersecurity globale. Non si tratta di un semplice aggiornamento tecnologico: è un cambio di paradigma nella gestione del rischio informatico aziendale.

SOC troppo costoso, SIEM insufficiente: il gap operativo che l’MDR colma

Per comprendere perché il Managed Detection and Response stia guadagnando terreno con tanta rapidità, è utile partire da ciò che non funziona nei modelli tradizionali di sicurezza informatica.

Un Security Operations Center (SOC) interno garantisce controllo e personalizzazione, ma richiede infrastrutture, personale altamente qualificato e processi strutturati che solo una minoranza di aziende può permettersi. Un sistema di monitoraggio classico basato su SIEM e raccolta di log produce volumi enormi di alert, la maggior parte dei quali sono falsi positivi che consumano tempo prezioso senza generare valore reale.

Il risultato è prevedibile: team IT esausti, minacce reali sepolte sotto tonnellate di rumore digitale e un senso diffuso di impotenza di fronte a un panorama delle minacce che evolve più velocemente delle capacità difensive interne.

Un servizio MDR interviene esattamente in questo spazio critico: non si limita a raccogliere segnali, ma li analizza, li valida e li trasforma in azioni concrete. È la differenza tra ricevere un allarme e avere qualcuno che risponde alla porta sapendo già se si tratta di un’emergenza reale o di un falso allarme.

NovaMDR™: tecnologia XDR e analisti umani per la cybersecurity aziendale italiana

In questo contesto si inserisce il lancio di NovaMDR™ sul mercato italiano, frutto della collaborazione tra Sangfor Technologies, leader globale nella cybersecurity e nel cloud computing abilitato all’intelligenza artificiale, e Forenova, provider europeo specializzato nei servizi di sicurezza gestita.

La soluzione combina una piattaforma XDR (Extended Detection and Response) con il SOC d’élite di Forenova, operativo 24 ore su 24 per 7 giorni su 7. Il vero punto di differenziazione non è però esclusivamente tecnologico: ogni alert viene convalidato da analisti esperti prima di tradursi in un’azione operativa. Questo presidio umano riduce drasticamente i falsi positivi e garantisce che le organizzazioni vengano allertate e supportate nella risposta solo quando esiste un rischio reale e verificato.

«Oggi la vera differenza non è solo intercettare una minaccia, ma sapere cosa fare nei primi minuti, quando l’impatto può ancora essere contenuto. Con NovaMDR™ trasformiamo un flusso continuo di dati e alert in decisioni operative concrete, validate da analisti esperti e attuate in tempo reale. La sicurezza non può più essere solo reattiva: deve essere gestita, proattiva e misurabile», afferma Jeffrey Zhang, Regional Manager Europa di Sangfor Technologies.

Il mercato dei servizi MDR in Italia sta crescendo in modo significativo, trainato dalla crescente consapevolezza delle imprese sui limiti degli strumenti di monitoraggio tradizionali e dalla pressione normativa derivante dalla Direttiva NIS2.

Rilevamento delle minacce in meno di 30 minuti: i KPI che fanno la differenza

Tra i parametri più significativi per valutare un servizio di Managed Detection and Response c’è il MTTD (Mean Time to Detect), ovvero il tempo medio necessario per identificare una minaccia attiva. NovaMDR™ punta a portare questo valore sotto i 30 minuti, con intervento immediato sugli incidenti reali già validati dagli analisti.

In un contesto in cui il ransomware può cifrare migliaia di file nell’arco di pochi minuti dall’attivazione del payload, questa metrica non è un dettaglio tecnico secondario: è la differenza concreta tra un incidente contenuto e una crisi aziendale a pieno regime.

Tra i benefici misurabili della soluzione figurano la riduzione significativa del carico operativo sui team IT interni grazie al filtraggio dei falsi positivi e alla contestualizzazione degli alert, la copertura completa di monitoraggio e threat hunting da parte di specialisti dedicati, l’ottimizzazione dei costi rispetto alla costruzione di un SOC interno con risparmi sostanziali su personale, licenze e infrastrutture, e il supporto strutturato alla compliance attraverso reportistica dettagliata e processi standardizzati.

Managed Detection and Response per PMI e grandi imprese: tre scenari reali

Una azienda manifatturiera con 150 dipendenti, nessun CISO interno e un responsabile IT che gestisce tutto da solo, dalla postazione del CEO alla rete di produzione: un SOC esterno dedicato costerebbe quanto assumere due specialisti senior, mentre un SIEM interno richiederebbe mesi di configurazione e competenze specialistiche non disponibili internamente. NovaMDR™ è progettato esattamente per questa realtà.

Oppure: uno studio professionale nel settore legale o sanitario, obbligato dalla normativa a garantire la riservatezza dei dati dei propri clienti, ma privo delle risorse per strutturare una funzione di sicurezza dedicata. O ancora una media impresa che fa parte della supply chain di un gruppo industriale più grande e deve dimostrare ai propri committenti un livello minimo di presidio cyber per mantenere i contratti.

In tutti questi scenari, NovaMDR™ offre una via concreta: protezione di livello enterprise, deployment completabile in pochi giorni, pacchetti di servizio modulari e un Customer Success Manager dedicato che adatta la soluzione alle esigenze specifiche dell’organizzazione, senza lunghi progetti di implementazione e senza costruire infrastrutture complesse da zero.

NIS2 e cybersecurity aziendale: l’MDR come risposta operativa alla compliance

C’è un ulteriore livello di urgenza che le imprese italiane devono considerare: quello normativo. La Direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024 entrato in vigore il 16 ottobre 2024, estende significativamente il perimetro dei soggetti obbligati a implementare misure di sicurezza adeguate, includendo ora anche fornitori e operatori di medie dimensioni in settori considerati critici o importanti.

Tra le misure richieste dalla norma figurano esplicitamente il monitoraggio continuo degli incidenti, la capacità di risposta rapida, la gestione della business continuity e la reportistica strutturata verso le autorità competenti. Un servizio come NovaMDR™ non è quindi soltanto uno strumento di difesa tecnica: è una vera e propria infrastruttura di compliance operativa. Fornisce la documentazione degli incidenti, i log di attività, le analisi post-incident e i processi standardizzati che le autorità e i clienti possono richiedere in caso di verifica o notifica obbligatoria.

Per le aziende che devono dimostrare la propria postura di sicurezza a committenti, partner o al regolatore, disporre di un servizio MDR attivo e documentato è sempre più un requisito contrattuale prima ancora che normativo.

Il fattore umano nella cybersecurity: perché l’AI da sola non basta

NovaMDR™ propone un approccio che va controcorrente rispetto a una narrativa dominante nel settore: quella secondo cui automazione e intelligenza artificiale possano sostituire integralmente il giudizio umano nella gestione della sicurezza informatica.

NovaMDR™ non nega il valore dell’AI: l’integrazione nativa con la piattaforma XDR garantisce visibilità profonda e correlata su rete e endpoint, con rilevamento automatizzato di pattern anomali. Sceglie però consapevolmente di collocare l’analista umano al centro del processo. Le decisioni di sicurezza e la responsabilità verso il cliente rimangono ancorate al team europeo, mentre la scalabilità tecnologica è garantita dall’ingegneria globale.

Un equilibrio che riflette una maturità nella comprensione del rischio: l’intelligenza artificiale individua, l’essere umano decide. In un dominio in cui le conseguenze di un falso negativo non gestito possono avere impatti economici e reputazionali di grande rilievo, questa filosofia non è conservatorismo tecnologico. È rigore metodologico applicato alla cybersecurity aziendale.

Sicurezza informatica proattiva: la domanda che ogni CISO dovrebbe porsi oggi

Il mercato MDR è in rapida espansione anche in Italia, spinto da una convergenza di fattori che non accenna a rallentare: pressione normativa crescente, shortage strutturale di talenti in cybersecurity, aumento della superficie di attacco legato alla digitalizzazione accelerata delle imprese.

Con oltre 4.500 clienti attivi in Italia tra pubblica amministrazione, sanità, università e imprese private, Sangfor Technologies porta su NovaMDR™ un patrimonio di esperienza concreta nel mercato locale, unito a una capacità di ingegneria globale che garantisce scalabilità e aggiornamento continuo delle capacità di rilevamento.

La vera domanda che ogni responsabile IT o CISO dovrebbe porsi non riguarda la probabilità di essere attaccati. Riguarda se, nel momento in cui accadrà, la propria organizzazione avrà gli occhi aperti oppure starà ancora analizzando i log del giorno precedente.

Per saperne di più su NovaMDR™ e sulle soluzioni di cybersecurity per le imprese italiane, visita www.sangfor.it.

https://www.ictsecuritymagazine.com/notizie/mdr-aziende-italiane/

Between the dates of Apr. 14 and Apr. 16, a sophisticated phishing campaign was observed targeting more than 35,000 users. This occurred across more than 13,000 organizations in 26 countries, with most targets in the United States (92%). 

The campaign focused on a variety of sectors, including: 

• Healthcare and life sciences (19%)
• Financial services (18%)
• Professional services (11%)
• Technology and software (11%)

The Microsoft Defender Research team observed several distinct waves of message distribution during the two days. 

In this campaign, emails posed as compliance or regulatory communications, claiming a “code of conduct review” had been launched. The emails included organization-specific names in the text and prompted targets open personalized attachments in order to review case materials. 

The emails appeared legitimate due to realistic-looking notices about the message being sent via an authorized internal channel as well as claims that links had been examined and approved for secure access. Additionally, messages contained a note at the end stating that contents were encrypted with Paubox, a trusted service connected with HIPAA-compliant communications.

Below, security leaders share their insights on this phishing campaign. 

Security Leaders Weigh In 

Mika Aalto, Co-Founder and CEO at Hoxhunt: 

Phishing is rarely the end goal. It’s typically the front door to something larger, including data theft, cloud compromise, or ransomware. Put it this way: If ransomware is the explosion, phishing is often the spark.

When phishing links lead to trusted cloud tools, collaboration platforms, or no-code services, the activity looks normal on the surface. That makes detection harder because users are no longer looking for red flags in grammar and mismatched URLs. They’re chasing behavior that blends into daily business operations. The new reality is that attackers don’t always break systems when they can borrow them.

Recent research found a step change at the turn of 2025 to 2026, when AI-generated phishing surged 14-fold almost overnight. The big shift isn’t brand-new tactics and zero-day messaging, it’s the modernization of old attacks. Traditional phishing kits are being upgraded with cleaner formatting, better writing, and more personalized messaging that can be generated at scale. Phishing never really went away. It just got an upgrade.

With that being said, people are trained to obey authority, and deepfake and callback phishing attacks are designed to push people into bypassing normal checks. Organizations need to normalize ‘see something, say something’ behavior and make verification frictionless. Behavioral monitoring tools can help flag unusual actions, but the real challenge is cultural: giving employees confidence that slowing down to verify is expected, supported, and reinforced through Human Risk Management practices.

Phishing has evolved beyond static text and awareness must do the same. The entire concept of ‘security awareness training’ is outdated if it stops at awareness. The next generation of defense is behavioral, not informational. We’re moving from telling people what to do to shaping what they actually do, in real time. We are building an essential set of security reflexes and instincts. 

James Maude, Field CTO at BeyondTrust:

With the rise of Adversary in the Middle (AiTM) toolkits such as EvilGinx and Phishing as a Service (PhaaS), we are seeing growing demand for a network of compromised devices to use as proxy exit nodes to make use of phished and compromised identities. The continued rise of identity threats and botnets is presenting a real challenge when it comes to enterprise security as many of their traditional defenses are simply not able to detect and prevent them in time. This is why is important to take an identity centric approach to security and focus on reducing your identity attack surface with least privilege and a holistic approach. Identity threats are here to stay, and with the rise of AI, we can only expect them to increase in scale.

Nicole Carignan, Senior Vice President, Security & AI Strategy, and Field CISO at Darktrace:

Traditional phishing emails once carried obvious warning signs, including poor grammar, inconsistent branding, or unusual formatting. Today, AI has removed many of those indicators. Attackers can generate highly polished, brand-consistent communications that closely mirror authentic organizations, and even tailor messages using publicly available or previously compromised data. 

At the same time, AI allows adversaries to operate with greater speed and precision. Campaigns can be created, tested, and refined in real time, producing huge volumes of highly targeted messages that are far more likely to succeed. As a result, phishing is no longer simply a volume-based threat, it’s become a quality and personalization problem, making it increasingly difficult to detect with the human eye alone. 

Rex Booth, Chief Information Security Officer at SailPoint:

The true danger of many phishing schemes lies in their ability to grant attackers access to credentials, enabling them to masquerade as trusted insiders. With AI in play, these campaigns are becoming increasingly sophisticated and harder to detect. This makes it imperative for users to adopt robust identity security best practices, including changing passwords frequently and enabling multi-factor authentication, and for organizations to prioritize identity as the new control plane.

We’ve been waiting for this offensive disruption from AI for a while now. Attacks at scale and superhuman speed are the most obvious first step. Fortunately, many campaigns still require human intervention to execute. The scarier scenario is when adversary AI starts running rampant through your enterprise without the need for action by the victim. 

https://www.securitymagazine.com/articles/102290-35-000-users-targeted-in-phishing-campaign-in-just-two-days

C’è una minaccia che non compare nei log di sicurezza, non genera alert sulle dashboard SIEM e non viene discussa nei consigli di amministrazione. Eppure erode la resilienza delle organizzazioni con una costanza che molti attori malevoli si sognerebbero: è il burnout dei professionisti della cybersecurity. Un fenomeno strutturale, non episodico, che nel 2025 e nel 2026 ha raggiunto dimensioni tali da rendere indifferibile una risposta sistemica.

I numeri di una crisi annunciata

I dati più recenti disegnano uno scenario allarmante. Il report The Human Cost of Vigilance di Sophos, condotto su 5.000 professionisti IT e cybersecurity in 17 paesi nel primo trimestre del 2025, ha rilevato che il 76% degli intervistati ha sperimentato cyber fatigue o burnout in modo costante, frequente o occasionale nell’arco del 2024. Il 69% ha dichiarato che il fenomeno è peggiorato rispetto all’anno precedente. Il 39% ha ammesso una riduzione della propria produttività lavorativa, il 33% un calo dell’engagement, mentre il 46% ha riferito un’ansia aumentata rispetto al rischio di cyberattacchi e violazioni dei dati.

Il report State of Cyber Risk and Exposure 2025 di Bitsight, basato su un campione di oltre 1.000 professionisti della sicurezza, ha fotografato una realtà analoga: il 47% ha dichiarato di vivere qualche grado di burnout, con oltre uno su dieci che descrive la propria condizione come acuta, vale a dire prossima all’abbandono della professione. Il report Voice of the CISO 2025 di Proofpoint si allinea su cifre simili: il 63% dei CISO ha vissuto o osservato direttamente episodi di burnout nel corso dell’anno.

I dati più aggiornati provengono dal 2026 State of the Cybersecurity Workforce Report di Seemplicity, condotto da Sapio Research su 300 responsabili della sicurezza negli Stati Uniti nel gennaio 2026 e pubblicato il 3 marzo. La ricerca documenta che i professionisti cyber lavorano in media 10,8 ore straordinarie settimanali oltre al contratto, il che equivale a una sesta giornata lavorativa. Il 45% supera le 11 ore extra a settimana, il 20% ne lavora più di 16 aggiuntive. Il 44% dichiara che il proprio ruolo è emotivamente più spossante che gratificante, una percentuale che sale al 56% tra i responsabili di livello C.

Non si tratta di statistiche isolate. Il 2026 SANS | GIAC Cybersecurity Workforce Research Report, presentato all’RSAC 2026 su un campione di 947 professionisti, responsabili HR e decision maker di sei regioni globali, documenta che il 61% delle organizzazioni registra un aumento dello stress nei team di sicurezza negli ultimi due anni. I principali fattori citati: sovraccarico di lavoro e sottodimensionamento degli organici (46%), vincoli di budget (40%) e complessità crescente delle minacce (40%).

Le cause strutturali: molto oltre la stanchezza

Sarebbe riduttivo leggere il burnout nella cybersecurity come semplice affaticamento da lavoro eccessivo. Le sue radici affondano in condizioni strutturali che nessuna misura di welfare aziendale può sanare da sola.

Alert fatigue: il paradosso della sorveglianza continua

Il Security Operations Center (SOC) è l’ambiente in cui la crisi si manifesta con maggiore intensità. La ricerca pubblicata sull’ACM Computing Surveys identifica quattro macro-cause di alert fatigue nel SOC: l’alto ritmo di generazione degli alert, il volume assoluto di notifiche, l’elevata percentuale di falsi positivi e la varietà crescente delle tipologie di minaccia, che rende rapidamente obsolete le regole di rilevamento basate su firme statiche.

I numeri operativi parlano da soli. Secondo l’AI SOC Market Landscape 2025, le organizzazioni affrontano in media 960 alert di sicurezza al giorno, con le realtà che superano i 20.000 dipendenti che ne gestiscono più di 3.000. Il SANS 2025 SOC Survey conferma che il 66% dei team non riesce a tenere il passo con i volumi in arrivo.

Una ricerca di Trend Micro, citata nell’analisi ACM, rileva che il 51% dei team SOC si sente sopraffatto dal volume degli alert, con gli analisti che spendono oltre il 25% del loro tempo a gestire falsi positivi. Il 40% degli alert non viene mai analizzato, mentre il 61% dei team ha ammesso di aver ignorato notifiche che si sono poi rivelate critiche.

L’effetto è pernicioso: l’analista si desensibilizza. Il segnale reale si perde nel rumore. E quella desensibilizzazione non è un’anomalia comportamentale: è una risposta adattiva del sistema nervoso umano a un input cognitivo insostenibile. Palo Alto Networks ricorda un caso emblematico: nella violazione Target del 2013, gli strumenti di sicurezza avevano rilevato correttamente il malware, ma gli analisti SOC, sepolti dagli alert, non avevano dato priorità ai segnali critici. Il danno fu la sottrazione di dati da oltre 40 milioni di carte di pagamento.

Understaffing e carichi asimmetrici

La carenza strutturale di talenti amplifica ogni altra causa. Il Cybersecurity Workforce Study 2024 di ISC2, condotto su un campione record di 15.852 professionisti, documenta che il 67% delle organizzazioni segnalava carenze di personale nei team di sicurezza, con un gap globale di posizioni scoperte pari a 4,8 milioni di ruoli a livello mondiale, in crescita del 19% rispetto all’anno precedente. Il report ISC2 del 2025, pubblicato a dicembre, rileva un leggero miglioramento nei livelli di organico, ma segnala per la prima volta che il problema della carenza di skill ha superato quello del puro headcount: il 59% dei professionisti indica lacune critiche o significative di competenze, contro il 44% dell’anno precedente.

La ricerca di Bitsight rileva una dinamica particolarmente rilevante: i team più piccoli sono doppiamente più esposti al burnout rispetto a quelli ben strutturati. Ma anche nei programmi ben dotati di risorse, quasi un professionista su quattro manifesta segnali di esaurimento. L’equazione è impietosa: meno personale significa carichi maggiori su chi resta, il che accelera il turnover, che a sua volta aggrava la carenza, in un ciclo autoalimentante.

Aspettative irrealistiche e cultura dell’eroismo

Un terzo vettore, spesso sottovalutato, è culturale. La cybersecurity esige una vigilanza paragonabile a quella dei controllori di volo o dei medici d’urgenza: un singolo errore può avere conseguenze catastrofiche e tracciabili. Questa responsabilità genera un carico emotivo che va ben oltre il volume di lavoro misurabile. Chi entra in questo settore lo fa spesso con forte motivazione identitaria, vale a dire con la consapevolezza di proteggere infrastrutture critiche, dati sensibili, vite umane. Quella stessa motivazione diventa combustibile per il burnout quando le condizioni organizzative non reggono il peso di quelle aspettative.

A questo si aggiunge un fenomeno emergente che James Lyne, CEO di SANS Institute, ha denominato AI fry: l’adozione massiccia di strumenti di intelligenza artificiale, pensata per alleviare i carichi di lavoro, produce paradossalmente un aumento del burnout attraverso il continuo cambio di contesto cognitivo. Come ha dichiarato Lyne all’RSAC 2026: «I rarely talk to teams that aren’t running some version of 100%». Le organizzazioni stanno sovrapponendo responsabilità di AI governance ai team di sicurezza senza ridisegnare i ruoli. Come ha osservato Ravid Circus, CPO di Seemplicity, a Help Net Security nel marzo 2026: aggiungere AI oversight senza riprogettare l’organizzazione accelera il burnout. È l’organigramma stesso che deve essere ripensato.

L’impatto sulla postura di sicurezza aziendale

Il burnout non è una questione di risorse umane. È una questione di rischio operativo. La catena di conseguenze che collega l’esaurimento dei professionisti alla vulnerabilità delle organizzazioni è documentata e misurabile.

Il report Sophos Human Cost of Vigilance documenta che il burnout riduce la produttività nel 39% dei casi e l’engagement nel 33%. Ma le conseguenze più gravi sono operative. Il 2026 SANS | GIAC Workforce Research Report documenta un dato diretto e inequivocabile: il 27% delle organizzazioni ha subìto violazioni reali come conseguenza diretta del gap di competenze e capacità nei team. Non di strumenti inadeguati, dunque, ma di persone esaurite, sopraffatte o assenti. Le lacune di skill producono anche ritardi nei progetti (57% delle organizzazioni), rallentamenti nella risposta agli incidenti (47%) e ridotta capacità di monitoraggio (42%).

Il Verizon 2025 Data Breach Investigations Report, basato sull’analisi di oltre 22.000 incidenti e 12.195 violazioni confermate, il dataset più ampio della storia del report, documenta che il ransomware è presente nel 44% delle violazioni (in crescita dal 32% dell’anno precedente) e che il coinvolgimento di terze parti è raddoppiato al 30%. Questi dati segnalano una superficie di attacco in rapida espansione che richiede team reattivi e lucidi, due qualità che il burnout erode sistematicamente.

Il Cost of a Data Breach Report 2025 di IBM, condotto dal Ponemon Institute su 600 organizzazioni globali tra marzo 2024 e febbraio 2025, fissa a 4,44 milioni di dollari il costo medio globale di una violazione e a 241 giorni la durata media del ciclo vita dell’incidente, il valore più basso da nove anni grazie all’adozione diffusa di AI e automazione. Le organizzazioni che non adottano questi strumenti, spesso proprio quelle con team sottorganico e sopraffatti, sperimentano tempi superiori ai 200 giorni, con costi medi che sfiorano i 5,49 milioni di dollari.

L’analista che ignora un alert perché ne ha già visti diecimila simili in settimana non sta fallendo come professionista: sta rispondendo razionalmente a un sistema progettato male. Il fallimento è organizzativo, non individuale.

Strategie di risposta: oltre il welfare aziendale

Le risposte efficaci al burnout nella cybersecurity richiedono un approccio a più livelli, che integri soluzioni tecnologiche, ridisegno dei processi e trasformazione culturale.

Automazione intelligente e SOAR di nuova generazione

La prima linea di difesa contro l’alert fatigue è tecnologica. Come approfondito su ICT Security Magazine nell’articolo dedicato alla security automation, le piattaforme SOAR (Security Orchestration, Automation and Response) nascono per automatizzare i task ripetitivi del SOC: triage degli alert, enrichment dei dati, lookup di threat intelligence, risposta iniziale agli incidenti. L’obiettivo è sottrarre all’analista il lavoro meccanico per restituirgli spazio cognitivo per le decisioni ad alto valore.

Le piattaforme di nuova generazione, basate su AI agentiva anziché su playbook statici, rappresentano un salto qualitativo rispetto ai sistemi tradizionali. Come sintetizza la ricerca pubblicata sull’ACM Computing Surveys, i SOC di sesta e settima generazione si muovono verso un ecosistema di collaborazione uomo-macchina in cui l’AI gestisce autonomamente correlazione, classificazione e risposta ai pattern ricorrenti, lasciando agli analisti i casi anomali, complessi o ad alto impatto strategico.

I sistemi che adottano AI-powered investigation raggiungono una copertura del 100% degli alert analizzati rispetto al 40-60% dei modelli tradizionali, con riduzioni documentate dei falsi positivi superiori al 70% nelle prime settimane di deployment. Il report IBM 2025 quantifica il vantaggio economico: le organizzazioni che utilizzano estensivamente AI e automazione nelle operazioni di sicurezza risparmiano in media 1,9 milioni di dollari sui costi di violazione e riducono il ciclo vita delle breach di 80 giorni.

Outsourcing SOC e modelli MDR

Non tutte le organizzazioni hanno la massa critica per costruire e mantenere un SOC interno di qualità. Per molte realtà, specialmente quelle medio-grandi che faticano a competere con le big tech nell’attrarre talenti, il ricorso a servizi di sicurezza gestiti (MSSP, MDR) non è una scorciatoia ma una scelta strategicamente razionale. Il report Sophos indica esplicitamente i servizi MDR come uno dei fattori più efficaci nel ridurre la cyber fatigue dei team interni.

Il trasferimento delle operazioni di monitoraggio continuativo a provider specializzati riduce il carico sui team interni, che possono concentrarsi su governance, architettura di sicurezza e gestione del rischio strategico. Questa redistribuzione dei ruoli, se ben progettata, non indebolisce la security posture: la rafforza, perché assegna ciascuna attività alla struttura che può sostenerla in modo sostenibile.

Ridisegno organizzativo e gestione del carico cognitivo

Le misure tecnologiche sono necessarie ma non sufficienti. Il problema del burnout nella cybersecurity è anche un problema di design organizzativo. Come analizzato su ICT Security Magazine nell’articolo sulle security operations aziendali, la tensione tra automazione massiva e mantenimento delle competenze umane è uno dei nodi irrisolti delle organizzazioni più mature.

La ricerca di Bitsight identifica nella visibilità sul rischio, vale a dire nella capacità di vedere, comprendere e priorizzare le minacce, il fattore che più di ogni altro correla con la resilienza psicologica dei team. Le organizzazioni dotate di asset discovery e risk monitoring strutturato mostrano un tasso di burnout del 44%, contro il 63% di quelle che ne sono prive. Sapere su cosa concentrarsi riduce l’ansia da omissione, quella paura costante di aver tralasciato qualcosa di critico, che è uno dei principali motori dell’esaurimento.

Sul piano operativo, il SANS 2025 SOC Survey ha rilevato che il 79% delle organizzazioni operative H24 sperimenta picchi di alert fatigue nelle transizioni di turno. Un dato che indica dove intervenire con processi strutturati di handover e contestualizzazione. Il monitoraggio sistematico dei carichi di lavoro degli analisti, la rotazione dei turni e la definizione esplicita di escalation path contribuiscono a distribuire la responsabilità e a ridurre il peso della vulnerabilità individuale percepita.

Cultura e responsabilità manageriale

L’ultimo, e forse più difficile, fronte di intervento è culturale. Il report Seemplicity 2026 rileva che il 43% dei CISO non riesce a prendere ferie senza accumulare stress aggiuntivo al rientro, e il 32% sperimenta regolarmente l’ansia anticipatoria della settimana lavorativa. Come ha sintetizzato Ravid Circus di Seemplicity: «This isn’t a talent retention story. It’s a system failure. The people aren’t leaving, but the system is breaking around them».

Invertire questo dato richiede che la leadership aziendale riconosca il burnout come un rischio operativo e non come un problema HR, inserendolo nel framework di gestione del rischio con la stessa serietà riservata alle minacce esterne. Questo significa metriche di benessere monitorate nei KPI di sicurezza, budget dedicati al dimensionamento adeguato dei team e una cultura che valorizzi la segnalazione precoce del sovraccarico anziché penalizzarla.

Cybersecurity burnout: una questione di sistema, non di resilienza individuale

È tentante leggere il burnout nella cybersecurity come un problema di persone che non reggono la pressione. È una lettura sbagliata e pericolosa. I professionisti della sicurezza affrontano un lavoro di guardia permanente su sistemi in costante espansione, in un panorama di minacce che si fa più sofisticato ogni anno, con organici spesso inadeguati, in un settore che non ammette errori e non dimentica quelli commessi.

Il vero rischio sistemico non è che qualcuno lasci la professione, anche se i dati sul turnover restano preoccupanti. È che migliaia di persone restino al loro posto, esaurite e desensibilizzate, gestendo le infrastrutture critiche di aziende, ospedali e istituzioni pubbliche con una frazione dell’attenzione che il loro lavoro richiede. Il SANS 2026 Workforce Report documenta con precisione questa escalation: tra le organizzazioni con significative lacune di skill, il 47% registra un aumento del burnout, il 57% subisce ritardi nei progetti critici e il 42% vede ridursi le proprie capacità di monitoraggio. Non è un problema di singoli individui: è una degradazione sistemica della security posture.

Il burnout dei team di sicurezza è una vulnerabilità. Una vulnerabilità che non compare nei rapporti di risk assessment, non viene patchata negli aggiornamenti software, non è nominata esplicitamente nei quadri normativi NIS2 o DORA. Ma che gli attaccanti, implicitamente e strutturalmente, sfruttano ogni giorno.

Affrontarla non è un atto di generosità verso i propri dipendenti. È un imperativo di sicurezza.

https://www.ictsecuritymagazine.com/articoli/cybersecurity-burnout/

I sistemi di intelligenza artificiale agentica, capaci di pianificare, agire e delegare in modo autonomo, stanno ridisegnando la superficie d’attacco delle organizzazioni a una velocità che i modelli di sicurezza tradizionali non riescono a seguire. Due ricerche peer-reviewed pubblicate all’inizio del 2026, rispettivamente sull’International Journal of Information Security di Springer e come preprint IEEE su arXiv, forniscono per la prima volta un framework sistematico per la valutazione di questi rischi.

I dati di mercato confermano l’urgenza: l’88% delle organizzazioni ha già subito incidenti legati ad agenti AI, mentre la quota di deployment approvati dai team di sicurezza non supera il 15%. L’articolo analizza i vettori d’attacco emergenti, le lacune strutturali nella governance e le implicazioni operative per CISO, security architect e compliance officer.

Oltre la generazione: quando l’AI comincia ad agire

Per anni il dibattito sulla sicurezza dell’intelligenza artificiale si è concentrato sui modelli linguistici nel loro senso più semplice: sistemi che ricevono un input e producono un output, sotto supervisione umana, in un ciclo chiuso. Quella stagione è finita.

I sistemi di AI agentica, detti anche AI agents, rappresentano una discontinuità qualitativa rispetto ai chatbot e ai modelli generativi di prima generazione. Non si limitano a rispondere: pianificano sequenze di azioni, utilizzano strumenti esterni, interrogano database, scrivono ed eseguono codice, coordinano altri agenti subordinati, aggiornano i propri piani in base ai risultati intermedi. Operano su orizzonti temporali estesi, spesso senza che un essere umano intervenga tra un’azione e la successiva. Sono, a tutti gli effetti, partecipanti attivi nell’infrastruttura aziendale.

Questa autonomia è esattamente ciò che li rende preziosi per le imprese e pericolosamente esposti agli attaccanti.

La ricerca scientifica inquadra il problema

Due contributi pubblicati nei primi mesi del 2026 hanno il merito di portare rigore scientifico in un campo che, fino ad oggi, era dominato principalmente da report di vendor e analisi di mercato.

Il primo, firmato da Leo, Tan, Miao e Anand, è apparso sull’International Journal of Information Security di Springer il 4 gennaio 2026 (vol. 25, art. 23).

Il lavoro costruisce il primo framework sistematico per la valutazione del rischio specifico dei sistemi agentici. I ricercatori identificano vettori d’attacco che non trovano corrispondenza nella tassonomia tradizionale della cybersecurity: la prompt injection indiretta, in cui istruzioni malevole vengono iniettate nei dati che l’agente consuma durante l’esecuzione; il memory poisoning, che altera la memoria a lungo termine del sistema compromettendone le decisioni future; la privilege escalation non autorizzata tra agenti, che sfrutta la fiducia implicita nei protocolli di comunicazione multi-agente. Il paper si concentra in particolare sui settori ad alto rischio, finanza e infrastrutture critiche, dove l’autonomia degli agenti si combina con l’accesso a sistemi di importanza sistemica.

Il secondo contributo, di Jiang, Yang, Yang e colleghi, è disponibile come preprint arXiv con copyright IEEE (arXiv:2602.19555, sottomesso il 23 febbraio 2026). I ricercatori analizzano come i sistemi agentici basati su LLM estendano la superficie d’attacco al runtime, il momento vivo dell’esecuzione, attraverso le dipendenze da strumenti e protocolli esterni.

Tra i dati più rilevanti del paper vi è la situazione dei registri MCP (Model Context Protocol), lo standard emergente per connettere i modelli a tool e sorgenti dati: i registri non ufficiali indicizzano, secondo le analisi disponibili a inizio 2026, una quantità di server circa otto volte superiore a quella del registro ufficiale, e la distinzione tra server verificati e non è spesso tutt’altro che immediata. La supply chain degli agenti è, per larga parte, opaca.

I due paper convergono su una diagnosi comune: la sicurezza agentica richiede framework dinamici, orientati al comportamento in esecuzione, che i modelli attuali, progettati per software statico, non sono in grado di fornire.

I numeri di un’adozione senza governance

I dati di mercato del primo semestre 2026 restituiscono un quadro che, nelle sue proporzioni, non ha precedenti in nessun altro ciclo tecnologico.

Il 48% dei professionisti della sicurezza identifica l’AI agentica e i sistemi autonomi come il principale vettore d’attacco emergente del 2026, superando deepfake, identità non-human e adozione del passwordless: è quanto emerge da un sondaggio condotto da Dark Reading. L’80,9% dei team tecnici ha già superato la fase di pianificazione, passando al testing attivo o al deployment in produzione; tuttavia, solo il 14,4% di questi agenti è andato live con la piena approvazione dei team di sicurezza e IT (fonte: State of AI Agent Security 2026, Gravitee).

Il gap tra fiducia manageriale e controllo operativo è uno dei dati più rilevanti. L’82% dei dirigenti dichiara di ritenere che le policy esistenti proteggano adeguatamente l’organizzazione da azioni non autorizzate degli agenti. I dati sul campo raccontano una storia diversa: oltre la metà degli agenti in produzione opera senza supervisione di sicurezza né logging (AGAT Software, 2026). Il 48,9% delle organizzazioni non è in grado di monitorare il traffico machine-to-machine generato dai propri agenti; il 48,3% non riesce a distinguere agenti AI legittimi da bot malevoli (fonte: 1H 2026 State of AI and API Security Report, Salt Security).

L’88% delle organizzazioni ha registrato incidenti di sicurezza confermati o sospetti legati ad agenti AI nell’ultimo anno; nel settore sanitario, la percentuale sale al 92,7% (Gravitee, State of AI Agent Security 2026). Non sono scenari ipotetici che vivono nei paper accademici: sono violazioni già avvenute.

I vettori d’attacco che ridisegnano il threat model

Comprendere perché l’AI agentica sia strutturalmente più esposta rispetto alle applicazioni tradizionali richiede un cambio di prospettiva sul threat modeling.

Prompt injection indiretta e tool poisoning. Un agente non consuma solo l’input dell’utente: legge documenti, naviga pagine web, interroga API, processa output di altri sistemi. Qualunque di questi canali può veicolare istruzioni malevole. Come approfondito nella nostra analisi sulla prompt injection negli agenti AI, Invariant Labs ha documentato nel maggio 2025 un caso esemplare: il server MCP ufficiale di GitHub ha permesso a una issue malevola, inserita in un repository pubblico, di iniettare istruzioni nascoste che hanno dirottato un agente attivando l’esfiltrazione di dati da repository privati. Il punto critico è che l’agente ha eseguito l’azione attraverso un tool legittimo: nessun firewall tradizionale avrebbe potuto intercettarla.

Memory poisoning e persistenza dell’attacco. I sistemi agentici mantengono memoria a lungo termine per supportare ragionamenti complessi su sessioni estese. La corruzione di questa memoria non produce effetti immediati visibili: altera silenziosamente le premesse su cui l’agente fonda le decisioni future. È un vettore particolarmente insidioso perché i suoi effetti emergono gradualmente e sono difficili da attribuire a una singola causa.

Escalation tra agenti e cascading failure. In architetture multi-agente, un agente orchestratore può detenere le credenziali di più agenti subordinati: se viene compromesso, l’attaccante ottiene accesso a tutti i sistemi downstream. Il paper di Jiang et al. illustra come un agente ricercatore compromesso possa inserire istruzioni nascoste nell’output consumato da un agente finanziario, che quindi esegue operazioni non autorizzate. La propagazione dei fallimenti è sistemica: simulazioni condotte da Galileo AI nel dicembre 2025 hanno documentato che un singolo agente compromesso può avvelenare l’87% del processo decisionale downstream entro quattro ore.

Shadow AI e identità non-human. Studi recenti indicano che circa tre quarti delle organizzazioni devono fare i conti con utilizzo non governato di strumenti AI da parte dei propri team. Sviluppatori e product manager deployano agenti autonomamente, connettendoli a tool, server MCP e API esterne che il team di sicurezza non ha mai mappato né approvato. Ogni agente introdotto è anche una nuova identità non-human che richiede credenziali, token OAuth, accesso API: sfide che i sistemi di identity management legacy non sono stati progettati per gestire.

Il problema strutturale: sicurezza progettata per artefatti statici

La diagnosi più profonda che emerge dalla letteratura recente è di natura architettonica.

La sicurezza informatica si è sviluppata, nei suoi decenni di storia, intorno a un presupposto implicito: i sistemi da proteggere sono sostanzialmente stabili. Un’applicazione ha una configurazione, un perimetro, un insieme definito di comportamenti possibili. Le policy di sicurezza si applicano a questi confini noti.

I sistemi agentici violano questo presupposto alla radice. Non hanno comportamenti fissi: apprendono dal contesto, si adattano agli ambienti che cambiano, prendono decisioni che non erano state anticipate dai loro sviluppatori. Il perimetro da difendere non è statico: si ridisegna ad ogni ciclo di inferenza, ad ogni interazione con un tool esterno, ad ogni messaggio scambiato con un agente coordinato.

Un firewall non ferma una prompt injection. Un API gateway non impedisce a un agente sovra-privilegiato di esfiltrare dati attraverso una chiamata a tool legittima. Le categorie della sicurezza tradizionale (perimetro, accesso, autenticazione) rimangono necessarie ma non sufficienti. Richiedono un complemento: visibilità comportamentale in tempo reale sull’esecuzione degli agenti. Su questo tema si innesta anche la lettura del cybercrime 2026, che documenta come gli attaccanti stiano già sfruttando sistematicamente questa lacuna.

Le implicazioni per il quadro regolatorio europeo

L’AI agentica non è un fenomeno che si sviluppa in un vuoto normativo. Il quadro europeo in costruzione, EU AI Act, NIS2 e DORA, pone requisiti che intersecano direttamente le caratteristiche di questi sistemi, anche se nessuno di questi strumenti è stato progettato specificamente per l’agenticità.

L’EU AI Act classifica come ad alto rischio i sistemi AI che operano in settori critici (infrastrutture, finanza, salute), con obblighi di trasparenza, supervisione umana e tracciabilità delle decisioni. Un agente che opera autonomamente su sistemi finanziari o sanitari rientra in questa classificazione, con tutto ciò che ne consegue in termini di documentazione e governance del ciclo di vita. Come abbiamo già analizzato nel nostro approfondimento sull’EU AI Act e il GPAI, la scadenza del 2 agosto 2026 per i sistemi ad alto rischio è ormai prossima.

La NIS2 impone la gestione del rischio della supply chain: e la supply chain degli agenti (modelli, plugin, server MCP, dataset di training) è esattamente il vettore che la ricerca identifica come più esposto. DORA richiede test di resilienza operativa per le entità finanziarie: requisito che include, implicitamente, i sistemi AI agentici integrati nelle operazioni core.

Una singola violazione su un agente AI dispiegato in un’istituzione finanziaria potrebbe attivare simultaneamente obblighi di notifica sotto tutti e tre i regimi, con tempistiche, soglie di materialità e autorità competenti differenti. È la sfida che i compliance officer stanno iniziando ad affrontare, spesso senza gli strumenti adeguati, come mostra la convergenza normativa NIS2, DORA e CER.

Verso una security posture agentica: principi operativi

La letteratura scientifica e i dati operativi convergono su un insieme di principi che, pur non esaustivi, possono orientare l’approccio delle organizzazioni.

Il primo è il least privilege per gli agenti: ogni sistema agentico dovrebbe operare con le autorizzazioni minime necessarie per completare il proprio task. Agenti sovra-privilegiati trasformano una singola prompt injection in una compromissione dell’intero ambiente. Il secondo è la visibilità sul runtime: il monitoraggio degli agenti non può limitarsi al momento del deployment, ma deve essere continuo, comportamentale, capace di rilevare derive rispetto al comportamento atteso.

Il terzo è la governance della supply chain agentica: ogni tool, server MCP, plugin o modello esterno integrato nell’ecosistema degli agenti è un potenziale vettore e richiede lo stesso processo di vetting applicato ai vendor software tradizionali. Il quarto è la tracciabilità delle decisioni: in un contesto regolatorio che richiede audit trail, ogni azione significativa di un agente deve essere loggata con sufficiente granularità da permetterne la ricostruzione post-incidente.

Questi principi non risolvono il problema, che ha radici strutturali profonde, ma definiscono il perimetro minimo di una postura difensiva consapevole.

Conclusione

C’è una tentazione, davanti a tecnologie che si diffondono così rapidamente, di considerare i rischi come un costo accettabile dell’innovazione, come un problema che si risolverà da solo con la maturazione del mercato. La storia della cybersecurity insegna che questa scommessa raramente paga.

I sistemi agentici stanno entrando nelle infrastrutture critiche, nelle operazioni finanziarie, nelle catene di fornitura software con una velocità che non ha precedenti. La ricerca scientifica, per sua natura più lenta del mercato, sta iniziando solo ora a produrre i framework concettuali necessari per comprenderne i rischi in modo sistematico. Il divario tra adozione e governo è reale, misurabile e si sta allargando.

La domanda rilevante non è se fermare questa transizione. È se le organizzazioni, e il sistema normativo che le inquadra, saranno in grado di colmare quel divario prima che diventi la prossima grande crisi della sicurezza digitale.

https://www.ictsecuritymagazine.com/articoli/ai-agentica/

C’è una verità scomoda che chiunque abbia mai operato in un SOC durante un incidente reale conosce bene: nessun corso, nessuna certificazione, nessuna slide può replicare la pressione di un attacco in corso. La differenza tra sapere e saper fare, in cybersecurity, si manifesta esattamente nel momento peggiore, quando i sistemi smettono di rispondere, i log sono incompleti, le comunicazioni interne si inceppano e il CISO chiede aggiornamenti ogni cinque minuti.

La formazione tradizionale, quella basata su aule, manuali e quiz di verifica, ha un merito innegabile: trasferisce conoscenza. Ma la conoscenza da sola non basta. Costruire un piano di risposta agli incidenti è diverso dall’eseguirlo sotto pressione. Leggere un playbook è cosa diversa dal seguirlo quando metà del team è in videoconferenza di crisi e l’altra metà sta ancora cercando di capire il vettore iniziale di compromissione.

È da questa consapevolezza che nasce il paradigma della formazione immersiva, che nel 2026 si è pienamente affermato: un approccio che non si limita a insegnare la teoria della risposta agli incidenti, ma simula le condizioni in cui quella risposta deve avvenire. Cyber range, esercitazioni tabletop avanzate, ambienti live-fire a scala nazionale sono strumenti che stanno ridisegnando il modo in cui le organizzazioni, i team SOC e gli incident responder si preparano all’evento che, prima o poi, arriverà. Come abbiamo già analizzato, nel 2026 la simulazione come strumento formativo ha fatto un salto qualitativo netto.

Cosa si intende per cyber range: architettura di un campo di addestramento digitale

Un cyber range è, nella sua essenza, un ambiente virtualizzato o ibrido che riproduce fedelmente infrastrutture IT e OT reali, tra cui reti aziendali, sistemi SCADA, ambienti cloud e dispositivi endpoint, all’interno del quale è possibile lanciare e subire attacchi senza alcun rischio per i sistemi di produzione.

La distinzione tra un cyber range e un semplice laboratorio di sicurezza sta nella complessità e nella fedeltà della simulazione. Un laboratorio può includere alcune macchine virtuali per esercitarsi su specifiche tecniche. Un cyber range replica la stratificazione di una vera infrastruttura critica, inclusi gli errori di configurazione, le interdipendenze tra sistemi e i limiti di visibilità tipici di una rete reale, e vi inserisce un team che deve operare esattamente come farebbe di fronte a un incidente vero.

I cyber range più evoluti integrano oggi diversi livelli di complessità: scenari tecnici che testano le capacità di rilevamento, contenimento e analisi forense; livelli strategici che coinvolgono decision maker chiamati a valutare l’impatto operativo e le opzioni di risposta; dimensioni legali e di comunicazione, perché un incidente reale genera sempre la necessità di notificare le autorità, gestire la comunicazione pubblica e valutare le implicazioni normative.

Questa architettura multi-livello è esattamente ciò che distingue la formazione immersiva da qualsiasi altra forma di preparazione: non allena singole competenze tecniche, ma la capacità del team di funzionare come sistema integrato sotto pressione.

Il panorama europeo: dalle esercitazioni nazionali ai grandi esercizi multinazionali

L’Europa dispone oggi di un ecosistema di esercitazioni cyber tra i più strutturati al mondo, con due pilastri che meritano attenzione particolare.

Cyber Europe: l’esercitazione pan-europea di ENISA

Organizzata dall’Agenzia dell’Unione Europea per la Cybersicurezza (ENISA) con cadenza biennale dal 2010, Cyber Europe è la più grande e complessa esercitazione di gestione delle crisi informatiche a livello europeo. La serie conta a oggi sette edizioni completate: Cyber Europe 2026 sarà l’ottava, pianificata per giugno 2026, con l’obiettivo di rafforzare la preparedness cyber delle infrastrutture critiche dell’UE. Quest’anno l’esercitazione si concentrerà sul settore dei trasporti, in particolare sui sottosettori ferroviario e marittimo identificati come ad alta criticità dalla NIS2.

La scelta del settore non è casuale. Secondo i dati analizzati nell’ultimo ENISA Threat Landscape, i trasporti rappresentano il secondo settore più colpito nel 2024, con l’11% del totale degli incidenti cyber e il 15% di quelli diretti verso l’UE. Il rapporto ENISA NIS360 2024 segnala inoltre che il settore marittimo si trova nella cosiddetta risk zone di maturità-criticità, mentre quello ferroviario ne è al limite: due settori con elevata criticità e margini significativi di miglioramento della postura cyber.

L’edizione precedente, Cyber Europe 2024 (settima della serie), si era svolta il 19 e 20 giugno in formato ibrido, con coordinamento del Centro di Controllo delle Esercitazioni di Atene. L’esercitazione ha simulato attacchi su larga scala alle infrastrutture energetiche europee in un contesto di tensione geopolitica con una nazione fittizia, testando la capacità di risposta e gestione della crisi su scala continentale.

Secondo l’After Action Report ENISA, Cyber Europe 2024 ha coinvolto circa 5.000 partecipanti, tra cui oltre 1.000 esperti operativi, provenienti dai settori energetico, delle infrastrutture digitali, della pubblica amministrazione e dalle istituzioni UE, con la partecipazione di 30 agenzie nazionali di cybersicurezza degli Stati membri UE e dei Paesi EFTA.

L’ACN italiana era tra i partecipanti. Il Direttore Generale Bruno Frattasi ha sottolineato come le esercitazioni siano parte integrante della Strategia Nazionale di Cybersicurezza 2022-2026, che alla misura 38 prevede periodiche esercitazioni interministeriali anche in ambito Perimetro di sicurezza nazionale.

Locked Shields: il live-fire exercise più complesso al mondo

Se Cyber Europe è l’esercitazione della gestione delle crisi, Locked Shields, organizzato dal NATO Cooperative Cyber Defence Centre of Excellence (CCDCOE) di Tallinn, è la massima espressione del live-fire training: attacchi reali, in tempo reale, su infrastrutture virtualizzate di scala nazionale, gestite dal cyber range operato dalla CR14 Foundation.

L’edizione 2025, svoltasi dal 5 al 9 maggio, ha visto quasi 4.000 esperti cyber da 41 nazioni impegnati a difendere più di 8.000 sistemi virtuali contro oltre 8.000 attacchi sofisticati, con 17 Blue Team multinazionali formati per rafforzare la cooperazione tra paesi. L’esercitazione ha raggiunto questo livello di complessità partendo da soli quattro paesi e 60 partecipanti nel 2010: quindici anni di crescita continua, rispecchiata nella scala degli organizzatori, con 450 pianificatori e sviluppatori e più di 25 partner industriali coinvolti nell’edizione 2025.

Lo scenario ha incluso tensioni geopolitiche, violazioni della sovranità e attacchi informatici su larga scala. Tra le innovazioni introdotte nel 2025: infrastruttura cloud-based, scenari con tematiche di quantum computing nel track di strategic decision-making, narrative guidate da AI su tutti i track principali e un sistema di punteggio ridisegnato per premiare collaborazione e resilienza.

Locked Shields 2026, svoltasi a Tallinn dal 20 al 24 aprile, ha riunito circa 4.000 partecipanti da 41 nazioni, organizzati in 16 squadre multinazionali. Il primo posto è stato conquistato dal team congiunto Lettonia-Singapore, seguito a pari merito dalle squadre Francia-Svezia e Germania-Austria-Lussemburgo-Svizzera.

L’edizione ha ampliato il segmento cloud, integrato sistemi aggiuntivi e introdotto una nuova categoria di Critical Special Systems a supporto degli sforzi di difesa nazionale, mentre sul fronte della ricerca interna l’obiettivo era avvicinarsi ulteriormente a un Blue Team completamente automatizzato.

Ciò che rende Locked Shields unico non è solo la scala: è la filosofia. L’esercitazione simula un conflitto cyber realistico su larga scala, testando capacità tecniche, operative e strategiche insieme alle capacità decisionali sotto pressione, e incorpora dimensioni legali e di comunicazione per forgiare quella mentalità da situazione di crisi che costringe i team a pensare rapidamente, adattarsi a minacce impreviste e collaborare con strutture di altri paesi.

Il panorama italiano: tra eccellenza pubblica e offerta privata

L’Italia dispone di un ecosistema di formazione immersiva articolato su tre livelli: quello istituzionale (con ACN e strutture universitarie), quello industriale (con i grandi player del settore difesa e cybersecurity) e quello emergente delle PMI e delle accademie specializzate.

Sul versante istituzionale, Cyber 4.0, il Centro di Competenza nazionale ad alta specializzazione per la cyber security con sede a Roma, include tra le proprie attività corsi erogati attraverso l’utilizzo di cyber range e strumenti di formazione immersiva, capaci di generare scenari complessi di cyber warfare entro cui eseguire sessioni pratiche. Il Centro è partner di Leonardo Cyber Academy nell’organizzazione di Cyber Shield, una competizione immersiva sviluppata sulle piattaforme di cyber range di Leonardo che simula le attività di analisi e gestione di un incidente di cybersecurity reale in formato a squadre con percorsi a difficoltà crescente.

HWG Sababa, tra i principali managed security provider italiani, premiata con cinque riconoscimenti ai Global InfoSec Awards 2026 durante la RSAC Conference, ha scelto un approccio non convenzionale alla formazione con il Cyber Bus: portare la formazione immersiva fuori dalle aule tradizionali, direttamente nei luoghi in cui la sicurezza digitale è realmente necessaria, tra cui aziende, scuole e pubbliche amministrazioni. Il metodo formativo si fonda su simulazioni pratiche, scenari realistici e momenti di confronto che pongono le persone al centro dell’interazione.

Sul versante globale dei cyber range as-a-service, Cloud Range ha ottenuto il riconoscimento Gold nella categoria Cyber Readiness and Validation dei 2026 Cybersecurity Excellence Awards. La piattaforma consente alle organizzazioni di misurare le capacità di team, processi, tecnologie e sistemi AI in condizioni che replicano un attacco reale, attraverso ambienti live-fire che coprono IT, OT/ICS, cloud e infrastrutture ibride.

IBM X-Force Cyber Range, attivo dal 2016 con oltre 17.000 leader aziendali formati, propone simulazioni gamificate che affrontano competenze tecniche, di leadership e di comunicazione per team di sicurezza, dirigenti e consigli di amministrazione, con facility fisiche a Cambridge (Massachusetts), Washington DC, Ottawa (in partnership con l’Università di Ottawa) e Bangalore.

Il programma è progressivamente stato esteso, con l’apertura nel marzo 2024 di un range dedicato alle agenzie federali e alle infrastrutture critiche americane, affiancando i format immersivi fissi con esperienze virtuali e mobile.

I modelli di esercitazione: una tassonomia operativa

La formazione immersiva non è un format unico. Esiste una progressione logica di modelli, ciascuno adatto a obiettivi e livelli di maturità diversi.

Tabletop Exercise (TTX). È il modello più accessibile: una sessione facilitata in cui i partecipanti, tra cui dirigenti, responsabili IT, legali e comunicazione, discutono verbalmente come risponderebbero a un incidente presentato dallo scenario. Non richiede infrastrutture tecniche, ma è straordinariamente efficace per identificare lacune nei processi decisionali, nella catena di comando e nei flussi di comunicazione. Il suo limite strutturale è che simula le discussioni, non le azioni.

Functional Exercise. Un gradino sopra: i team eseguono le proprie funzioni reali in risposta a uno scenario simulato, attivando procedure operative, comunicando con le autorità e coordinando la risposta. Non si toccano i sistemi reali, ma si esercitano i comportamenti organizzativi, i processi di escalation e le interfacce con i soggetti esterni, incluse le notifiche alle autorità competenti.

Live-fire Exercise su cyber range. Il livello più avanzato: attacchi reali contro infrastrutture virtualizzate, con team che rispondono in tempo reale. Qui si testano le competenze tecniche vere, dal rilevamento di intrusioni all’analisi forense, dal contenimento all’eradicazione, in condizioni di pressione autentica. È il formato adottato da Locked Shields, e la massima espressione di questo approccio formativo.

Red/Blue/Purple Team Exercise. Un modello che si integra con i cyber range: il Red Team (attaccante) testa le difese del Blue Team (difensore), mentre il Purple Team favorisce la condivisione delle conoscenze tra le due parti. La variante Purple è particolarmente utile per accelerare il miglioramento delle capacità di detection, riducendo il tempo che normalmente separa l’identificazione di una tecnica offensiva dalla sua integrazione nelle regole di rilevamento difensivo.

La scelta del modello dipende dalla maturità dell’organizzazione, dagli obiettivi formativi e dalle risorse disponibili. Un’organizzazione che non ha mai condotto un TTX non è pronta per un live-fire exercise su cyber range: i due strumenti non si escludono, ma si costruiscono l’uno sull’altro in una progressione logica.

Costi, benefici e il calcolo che le organizzazioni evitano di fare

Il tema dei costi è spesso usato come alibi per rimandare la formazione immersiva. Vale la pena affrontarlo con onestà.

L’implementazione di un cyber range proprietario, con hardware dedicato, software di orchestrazione e scenari sviluppati su misura, richiede investimenti significativi, nell’ordine delle centinaia di migliaia di euro per soluzioni enterprise complete. È una soglia che giustifica la scelta di piattaforme cloud-based o di servizi gestiti, dove il costo si trasforma in un canone operativo accessibile anche a organizzazioni medie.

Il beneficio va misurato non solo in termini di competenze acquisite, ma di rischio ridotto. Secondo l’IBM Cost of a Data Breach Report 2025, che ha analizzato 600 organizzazioni colpite da violazioni tra marzo 2024 e febbraio 2025, il costo medio globale di un data breach è di 4,44 milioni di dollari, in calo del 9% rispetto ai 4,88 milioni del 2024 grazie a detection più rapida abilitata da strumenti AI.

Le organizzazioni che fanno uso estensivo di AI e automazione nella propria sicurezza hanno risparmiato in media 1,9 milioni di dollari per violazione e hanno ridotto il ciclo di vita della violazione di 80 giorni. Nello stesso rapporto, le organizzazioni che avevano costituito un team di incident response e testato regolarmente il proprio piano IR hanno registrato tempi di risposta più rapidi e costi inferiori rispetto a quelle che non avevano fatto né l’uno né l’altro.

Il nesso causale è diretto: formare i team in ambienti simulati equivale a testare i piani di risposta, e testare i piani di risposta riduce l’impatto economico degli incidenti reali.

C’è poi un beneficio meno quantificabile ma non meno reale: la coesione del team. Un esercizio di cyber range rivela come funziona davvero un team sotto pressione, chi guida, chi si blocca, dove si creano colli di bottiglia comunicativi. Questi elementi raramente emergono nei corsi tradizionali e sono invece determinanti nella gestione di un incidente reale.

L’integrazione con NIS2: dalla compliance alla preparedness operativa

Con il 2026, l’Italia è entrata nella fase decisiva dell’implementazione della Direttiva NIS2 (D.Lgs. 138/2024). Le implicazioni per la formazione sono dirette e cogenti, e il quadro normativo continua a evolversi.

Il 20 gennaio 2026, la Commissione europea ha proposto emendamenti mirati alla NIS2 per aumentare la chiarezza giuridica e semplificare la compliance, con misure che interesseranno circa 28.700 aziende, di cui 6.200 micro e piccole imprese. Il perimetro viene ampliato ai provider di wallet digitali e agli operatori di infrastrutture sottomarine. Il quadro normativo è dunque in movimento, e le organizzazioni già in percorso di adeguamento dovranno tenerne conto nell’aggiornamento dei propri piani.

Sul fronte italiano, tra le principali novità della Direttiva figura l’obbligo di formazione continua per i componenti degli organi di gestione: non un semplice corso una tantum, ma aggiornamenti a cadenza regolare che vedono i CdA coinvolti in prima linea. La sicurezza informatica cessa di essere un tema delegabile ai soli team tecnici e diventa elemento strutturale della governance aziendale.

Le Linee Guida NIS – Specifiche di base pubblicate dall’ACN il 4 settembre 2025 hanno individuato, all’Appendice C, undici documenti strategici che devono essere formalmente approvati dagli organi apicali, tra cui il piano di gestione del rischio, i piani di business continuity e disaster recovery, il piano di risposta agli incidenti e il piano di formazione in materia di sicurezza informatica.

Il 24 dicembre 2025 è stata pubblicata la Determinazione ACN n. 379907/2025, che ha aggiornato e consolidato le misure di sicurezza di base e i criteri per gli incidenti significativi sostituendo la precedente Determinazione n. 164179/2025 del 14 aprile 2025. Entrata in vigore il 15 gennaio 2026, da quella data è pienamente operativo l’obbligo di notifica degli incidenti significativi al CSIRT Italia.

L’obbligo di adozione delle misure di sicurezza è invece fissato a ottobre 2026, a 18 mesi dall’inserimento nell’elenco nazionale NIS. Da quella data l’ACN potrà avviare le attività ispettive, transitando dalla fase di accompagnamento alla fase di verifica vera e propria. Per una mappa completa delle scadenze e degli adempimenti tecnici, si rimanda alla nostra guida agli adempimenti NIS2.

Il punto critico è questo: NIS2 non prescrive un numero di ore di formazione né un tipo specifico di esercitazione. Prescrive la sostanza, ovvero che le organizzazioni siano effettivamente preparate a rilevare, gestire e notificare gli incidenti. La formazione immersiva è lo strumento più diretto per dimostrare, anche in sede ispettiva, che questa preparazione esiste e viene mantenuta nel tempo.

Come integrare la formazione immersiva nel piano annuale: un approccio pratico

La costruzione di un programma di formazione immersiva che risponda agli obblighi NIS2 e generi valore operativo reale segue una logica progressiva.

Il punto di partenza è la valutazione della maturità attuale: dove si trovano i gap più significativi, nella detection, nel contenimento, nella comunicazione interna, nel coordinamento con le autorità? Questa valutazione orienta la scelta del modello di esercitazione più adatto e alimenta direttamente il piano di formazione in materia di sicurezza informatica che le Linee Guida ACN richiedono tra i documenti da approvare formalmente dagli organi apicali.

Per le organizzazioni che si avvicinano per la prima volta alla formazione immersiva, un tabletop exercise ben progettato su uno scenario realistico, come un ransomware che blocca i sistemi operativi o un’esfiltrazione di dati via fornitore compromesso, è il punto di partenza ideale. Richiede poche risorse, coinvolge il management e produce una lista di gap da colmare che diventa la roadmap per i passi successivi.

Il passo successivo è un functional exercise che attivi i processi reali di incident response: notifica al CSIRT Italia nei termini previsti dalla Determinazione ACN 379907/2025, comunicazione alla direzione, coordinamento con il team legale. Questo livello rivela le criticità procedurali che il tabletop non può intercettare.

Solo a questo punto il live-fire exercise su cyber range ha senso: i team che lo affrontano hanno già validato i propri processi e possono concentrarsi sul testare le competenze tecniche in condizioni di pressione autentica.

La frequenza ideale è almeno un’esercitazione tabletop per semestre, un functional exercise annuale e un cyber range exercise ogni uno o due anni. Per le organizzazioni classificate come soggetti essenziali, che operano in settori ad alta criticità come energia, sanità, infrastrutture digitali e trasporti, la frequenza dovrebbe essere superiore, anche in ragione dei requisiti più stringenti previsti dalla Determinazione ACN.

Una riflessione finale: la preparazione come investimento culturale

C’è una tensione irrisolta nel modo in cui molte organizzazioni affrontano la formazione in cybersecurity: la trattano come un costo da minimizzare piuttosto che come un investimento da ottimizzare. Il risultato è che si acquistano certificazioni, si compilano moduli di compliance, si aggiornano i piani di incident response e poi questi piani restano nei cassetti fino al momento in cui qualcuno si trova davvero a dover gestire un incidente.

Nel 2026 il gap di competenze nella cybersecurity non si è chiuso: si è ampliato, perché la velocità di evoluzione delle minacce e delle tecnologie supera sistematicamente la velocità di formazione dei professionisti. I cyber range e la formazione immersiva non sono la risposta definitiva a questo problema strutturale, ma sono lo strumento più efficace per ridurre la distanza tra quello che i team sanno e quello che sono in grado di fare quando conta davvero.

La cultura della preparedness non si costruisce con una singola esercitazione annuale. Si costruisce con la ripetizione, con il feedback strutturato, con la capacità di apprendere dagli errori commessi in un ambiente sicuro invece che durante un incidente reale. Si costruisce, in altre parole, esattamente come si costruisce qualsiasi altra competenza operativa ad alto rischio: attraverso la pratica deliberata, sistematica e rigorosa.

I team che saranno davvero pronti all’incidente reale non sono quelli che hanno fatto il corso giusto. Sono quelli che hanno già vissuto, almeno una volta, la pressione di un attacco, anche se simulato, e sanno cosa fare quando arriva quello vero.

https://www.ictsecuritymagazine.com/articoli/cyber-range/

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

---

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

Perché Copy Fail è così pericolosa

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

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

Il cuore tecnico: AF_ALG, algif_aead e page cache

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

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

Perché quattro byte bastano per ottenere root

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

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

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

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

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

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

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

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

L’exploit è affidabile e già pubblico

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

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

Mitigazione: aggiornare il kernel e ridurre la superficie

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

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

---

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

---

---

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

Trellix, fra i principali fornitori globali di soluzioni Extended Detection and Response, ha reso noto di aver subito un accesso non autorizzato a una porzione del proprio repository di codice sorgente. La nota, pubblicata sul sito istituzionale dell’azienda, è essenziale ma inequivocabile e arriva in una fase in cui la sicurezza dei vendor di cybersecurity è tornata al centro dell’agenda regolatoria europea.

Nel comunicato pubblicato sul sito ufficiale, Trellix dichiara di aver «recentemente identificato» l’intrusione, di aver coinvolto senza indugio esperti forensi esterni e di aver notificato l’incidente alle autorità di law enforcement. Allo stato attuale dell’investigazione, l’azienda afferma di non aver riscontrato alcuna evidenza che il processo di rilascio o di distribuzione del codice sia stato compromesso, né che il codice esposto sia stato sfruttato in attacchi attivi.

Trellix, cosa è stato comunicato e cosa resta opaco

Il testo diffuso da Trellix lascia in sospeso elementi che, in un’investigazione ancora aperta, sono dirimenti per misurare il perimetro reale del danno. Come riporta Security Affairs, l’azienda non ha precisato l’identità dei threat actor, la finestra temporale durante la quale è stato mantenuto l’accesso, né la natura esatta dei dati esposti. Il comunicato si limita ad anticipare che ulteriori dettagli verranno condivisi con la comunità di sicurezza al termine delle verifiche.

Sul piano industriale, il bersaglio è di assoluto rilievo. Nata a gennaio 2022 dalla fusione tra McAfee Enterprise e FireEye sotto Symphony Technology Group, Trellix offre soluzioni di endpoint security, email security, threat intelligence e incident response a imprese e amministrazioni in tutto il mondo. La superficie di esposizione potenziale, in termini di clienti finali integrati con i prodotti del gruppo, è dunque tutt’altro che marginale.

Perché un repository di codice sorgente è un bersaglio strategico

La compromissione di un repository di codice sorgente rappresenta uno degli scenari più sensibili nell’ecosistema della cybersecurity, e lo è a maggior ragione quando il bersaglio è un’azienda che produce software di sicurezza. Il codice è la blueprint tecnica del prodotto: chi vi accede non deve ipotizzare dove cercare le vulnerabilità, ma può leggerle direttamente nelle logiche implementative, nelle API interne, nelle credenziali eventualmente lasciate hard coded dai team di sviluppo e nelle euristiche di rilevamento utilizzate dai motori di protezione.

Anche in assenza di manomissioni rilevate sui binary distribuiti, l’esposizione del codice fornisce ad avversari sofisticati un valore di intelligence di lungo periodo: insight sulle tecniche di rilevamento, possibili percorsi di detection evasion, mappatura delle integrazioni con gli ambienti dei clienti. Il rischio non è quindi tanto immediato quanto strategico, in linea con i modus operandi tipicamente attribuiti agli attori nation state.

E’ necessario mette a fuoco tre vettori specifici. Il primo è la possibilità di sviluppare tecniche di detection evasion attraverso l’analisi della logica interna e delle euristiche del prodotto. Il secondo è l’accelerazione nella scoperta di debolezze e di edge case nei controlli difensivi. Il terzo è il valore di intelligence aggiuntivo per chi intenda colpire ambienti integrati con prodotti Trellix. Nessuno dei tre richiede, per concretizzarsi, una manomissione preventiva della build pipeline: la sola lettura del codice basta.

Una sequenza di precedenti, dal caso SolarWinds in poi

L’episodio si colloca in una sequenza che, negli ultimi anni, ha colpito alcuni dei vendor di sicurezza e dei fornitori tecnologici più rilevanti a livello globale. Come ricostruisce The Hacker News, incidenti analoghi hanno interessato in passato Microsoft, Okta e LastPass.

Nel marzo 2022 il gruppo Lapsus$ rivendicò l’esfiltrazione di codice sorgente di prodotti Microsoft, fra cui Bing, Cortana ed Exchange. Due anni più tardi, nel marzo 2024, Microsoft confermò con depositi 8-K presso la SEC che il gruppo Midnight Blizzard, attribuito al servizio di intelligence estera russo (SVR), aveva avuto accesso a parti dei propri repository di codice sorgente e ad alcuni sistemi interni, dopo l’iniziale compromissione di account di posta corporate. La memoria del settore richiama poi la violazione di SolarWinds del 2020, con l’inserimento del backdoor Sunburst nella build pipeline di Orion e la successiva distribuzione fraudolenta tramite canali ufficiali; l’attacco a Kaseya nel 2021; le esfiltrazioni subite da LastPass nel 2022; le ripetute violazioni di Okta tra 2022 e 2023.

La logica dell’attaccante è economica prima ancora che tecnica. Violare un fornitore che protegge centinaia o migliaia di clienti significa rendere potenzialmente accessibile l’intero perimetro a valle, con un rapporto sforzo-beneficio incomparabilmente più favorevole rispetto a una compromissione individuale. È la dinamica che ha reso strutturale il rischio di supply chain nel comparto cyber e che, sul versante regolatorio, alimenta la richiesta di garanzie più stringenti sui processi interni dei vendor. Su ICT Security Magazine, l’analisi degli attacchi alla supply chain software ha già documentato come, nel 2025 e nel 2026, il fenomeno abbia raggiunto dimensioni quantitative inedite, con centinaia di migliaia di pacchetti malevoli e operazioni state-sponsored di portata sistemica.

Le implicazioni per la secure software supply chain e il quadro normativo

Il caso Trellix rilancia la riflessione sulla secure software supply chain applicata agli stessi fornitori di sicurezza. Il Cyber Resilience Act dell’Unione europea, Regolamento (UE) 2024/2847, è entrato in vigore il 10 dicembre 2024. Gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi si applicheranno dall’11 settembre 2026, mentre gli obblighi a regime, compresi quelli relativi al Software Bill of Materials, decorreranno dall’11 dicembre 2027. Per le violazioni più gravi è prevista una sanzione massima fino a 15 milioni di euro o al 2,5 per cento del fatturato annuo globale.

Il SBOM, disciplinato dall’articolo 13 e dall’Allegato I del Regolamento, dovrà essere prodotto in formato machine-readable e coprire almeno le dipendenze di primo livello, restando parte integrante della documentazione tecnica e fornito alle autorità di vigilanza su richiesta. Per un’analisi operativa su come implementare un SBOM conforme al CRA, ICT Security Magazine ha pubblicato una guida dedicata che ricostruisce workflow, formati (SPDX e CycloneDX), strumenti open source e integrazione nelle pipeline di vulnerability management.

In questo scenario, audit del Secure Development Lifecycle, code signing robusto, monitoraggio continuo dei repository, gestione delle identità privilegiate e segregazione degli ambienti di sviluppo cessano di rappresentare best practice opzionali per diventare requisiti minimi di credibilità di mercato. Il presupposto è semplice: la posture interna di un vendor di sicurezza non è un fatto privato, ma una componente diretta del rischio dei suoi clienti.

Per le organizzazioni che utilizzano soluzioni Trellix, e più in generale per chi si affida a piattaforme XDR e di endpoint protection, la postura prudenziale resta quella indicata da Integrity360: nessuna azione emergenziale è richiesta in questa fase, ma è essenziale applicare con costanza gli aggiornamenti rilasciati dal vendor, monitorare i comportamenti anomali negli ambienti integrati con i prodotti Trellix e mantenere un’architettura di sicurezza fondata sul principio della defense in depth.

Conclusione analitica

L’episodio Trellix non si misura sull’entità del codice esposto, al momento non quantificabile pubblicamente, ma sul segnale che invia al mercato. La comunicazione tempestiva, l’attivazione di forensi esterni e il coinvolgimento delle autorità descrivono un modello di gestione che, sul piano reputazionale, è ormai un’aspettativa più che un’eccezione. Resta tuttavia aperto il nodo sostanziale: se anche un vendor di sicurezza con risorse di livello enterprise può subire un accesso non autorizzato a un repository, la vera variabile competitiva non è più la presunta inviolabilità, ma la qualità dei processi di rilevamento, contenimento e trasparenza. È in questa cornice che andrà letta, nelle prossime settimane, la pubblicazione dei dettagli tecnici annunciata dall’azienda.

https://www.ictsecuritymagazine.com/notizie/trellix-violazione-codice/

C’è una domanda che i professionisti della sicurezza informatica si pongono con crescente frequenza: quando un attacco viene rivendicato da un gruppo che si autodefinisce “hacktivista”, chi sta davvero premendo il tasto? La risposta, nel 2026, è raramente univoca. E questa ambiguità non è accidentale: è progettuale.

Il panorama della conflittualità digitale si è trasformato radicalmente nell’arco di pochi anni. Non vi è più una netta separazione tra operazioni di Stato, criminalità organizzata e attivismo politico. Al loro posto si è affermato un modello ibrido, fluido, deliberatamente opaco: quello dei cyber mercenari e dei cosiddetti patriotic hackers, attori formalmente non statali ma funzionalmente allineati agli interessi di governi che li tollerano, li finanziano, li dirigono o, nella migliore delle ipotesi per chi subisce l’attacco, semplicemente non li fermano.

La zona grigia come dottrina

Per comprendere il fenomeno, occorre smettere di ragionare in categorie binarie. La distinzione tra “hacker di Stato” e “hacktivista indipendente” è ancora utile sul piano teorico, ma sempre meno praticabile sul piano operativo.

Il caso russo è il più documentato. La Chatham House, in un’analisi del marzo 2026, descrive l’ecosistema di cyber proxy russi come uno spettro di attori che operano con diversi gradi di direzione statale, sponsorizzazione o semplice allineamento con gli obiettivi del Cremlino. Alcuni proxy sono stati collegati direttamente ai servizi di intelligence come il GRU, altri sono sponsorizzati a distanza di sicurezza, altri ancora sono semplicemente tollerati perché le loro azioni coincidono con la linea strategica di Mosca. Il vantaggio di questa struttura è evidente: l’uso di proxy garantisce alla Russia la negazione plausibile, complica l’attribuzione degli attacchi e aiuta lo Stato, così come i singoli attori, a sfuggire alle sanzioni internazionali.

Non si tratta di una particolarità russa. Russia, Cina e Iran si avvalgono sistematicamente di organizzazioni hacktiviste come strumenti per mascherare la propria agenda strategica: destabilizzare gli Stati Uniti e altri Paesi occidentali, proiettare influenza regionale e imporre costi asimmetrici agli avversari. Secondo le stime di CACI, il 75-80% delle minacce informatiche che prendono di mira le nazioni occidentali è oggi riconducibile ad attori sponsorizzati dagli Stati, in particolare quelli sostenuti da Russia, Iran e Cina. Il restante 20-25%, pur apparentemente indipendente, è spesso guidato da motivazioni politiche strutturalmente allineate agli obiettivi delle potenze che ne beneficiano.

Come analizzato in un approfondimento su attori non statali pubblicato su queste pagine, la globalizzazione ha frammentato il quadro strategico tradizionale, favorendo l’ascesa di soggetti capaci di operare nel cyberspazio come proxy strategici, collocandosi in una zona grigia tra guerra informativa, conflitto armato e competizione geopolitica.

Killnet e il modello “Wagner Digitale”

Nessun gruppo incarna meglio questa metamorfosi di Killnet. Nato come collettivo di hacktivisti filo-russi nel contesto dell’invasione dell’Ucraina, si è reso noto per una serie di campagne Distributed Denial of Service (DDoS) contro infrastrutture di governi e aziende in Europa e negli Stati Uniti: tra queste, nel gennaio 2023, una serie di attacchi contro siti tedeschi in risposta alla decisione di Berlino di fornire carri armati all’Ucraina. Il fondatore del gruppo, noto con lo pseudonimo Killmilk, ha dichiarato di voler trasformare Killnet in una “private military hacking company”, riorganizzandola sotto il nome Black Skills e iniziando ad accettare commissioni da entità private e pubbliche.

Il modello dichiarato di ispirazione è rivelatore. Killmilk ha preso a riferimento la Wagner Private Military Company, i mercenari paramilitari di Evgeny Prigozhin, per costruire un equivalente digitale, con unità di HR, formazione e operazioni su larga scala. Come Wagner operava nelle zone grigie del conflitto armato convenzionale, Black Skills ambisce a operare nella zona grigia del conflitto digitale: mercenari per elezione, non per necessità ideologica.

Come ha sottolineato Flashpoint in più occasioni, Killnet è sempre rimasto un gruppo principalmente motivato finanziariamente, che ha sfruttato l’esposizione mediatica offerta dall’ecosistema mediatico filo-Cremlino per promuovere i propri servizi di DDoS-for-hire. Il nazionalismo era, almeno in parte, una strategia di marketing. Con la svolta mercenaria dichiarata, quella maschera è caduta. Ciò che rimane è un blueprint operativo che altri gruppi possono replicare.

La replicazione è già in atto. Nel marzo 2025 è emerso un nuovo collettivo, denominato IT Army of Russia, che comunica attraverso il forum cybercriminale Duty-Free e un canale Telegram con oltre 800 iscritti, pubblica presunte violazioni di siti ucraini, sottrae dati e recluta insider operativi nelle infrastrutture critiche ucraine. Le operazioni sono coordinate attraverso un bot Telegram che incoraggia gli utenti a fornire intelligence militare e a suggerire nuovi obiettivi. Il ciclo si ripete e si moltiplica.

L’IT Army of Ukraine: hacktivismo sanzionato dallo Stato

Sul fronte opposto si colloca un esperimento altrettanto rivoluzionario, e altrettanto problematico sul piano del diritto internazionale. L’IT Army of Ukraine è una forza cibernetica volontaria e crowdsourced, istituita il 26 febbraio 2022 e annunciata da Mykhailo Fedorov, Ministro della Trasformazione Digitale dell’Ucraina, attraverso Twitter. Il canale Telegram coordinato raggiunse rapidamente oltre 300.000 iscritti entro marzo 2022, tra professionisti IT, volontari amatoriali e osservatori internazionali, diventando la prima milizia digitale pubblicamente organizzata impiegata come componente formale della difesa nazionale in un conflitto armato maggiore.

Nel corso del 2022, l’IT Army ha condotto operazioni offensive contro i siti della Borsa di Mosca, Sberbank, il Ministero degli Esteri russo, Gazprombank e l’infrastruttura di rete di Loesk, utility elettrica che alimenta l’Oblast di Leningrado. Secondo ricercatori specializzati, la struttura pubblica dell’IT Army ha progressivamente ceduto spazio a un nucleo interno più ristretto, composto da personale dell’intelligence e della difesa ucraina, che ha guidato operazioni più sofisticate e mirate.

L’IT Army ha ispirato imitatori su entrambi i fronti. Gruppi filo-russi, tra cui NoName057(16), hanno adottato il modello di coordinamento crowdsourced in senso inverso, orchestrando campagne DDoS contro governi NATO, istituzioni finanziarie europee e operatori di infrastrutture critiche.

Nel luglio 2025, il collettivo NoName057(16) è stato oggetto dell’Operation Eastwood, coordinata da Europol ed Eurojust: l’operazione ha portato allo smantellamento di oltre 100 server, a due arresti in Francia e in Spagna, all’emissione di sette mandati d’arresto internazionali (sei dei quali dalla Germania contro cittadini russi) e a 24 perquisizioni condotte in Germania, Lettonia, Spagna, Italia, Cechia, Polonia e Francia. Cinque profili sono stati pubblicati sul sito EU Most Wanted. Il gruppo ha ripreso le operazioni già il giorno successivo, rivendicando nuovi attacchi contro siti governativi tedeschi.

Il caso dell’IT Army solleva questioni giuridiche irrisolte. Poiché il gruppo si dichiara indipendente dalle forze armate ucraine e i suoi volontari non indossano una divisa, non rientrano formalmente nella categoria di combattenti. Se tuttavia contribuiscono, anche marginalmente, allo sforzo bellico militare ucraino, diventano potenzialmente un obiettivo legittimo per le forze russe. La smilitarizzazione formale non equivale a neutralità operativa.

Iran: il modello Layered dell’ecosistema proxy

Mentre il conflitto russo-ucraino ha reso familiare il fenomeno dei cyber proxy, è nel contesto mediorientale che il modello ha raggiunto la sua espressione più sofisticata. L’Iran ha costruito un ecosistema informatico deliberatamente stratificato: attori Advanced Persistent Threat (APT) sponsorizzati dallo Stato, appartenenti al Corpo delle Guardie della Rivoluzione Islamica (IRGC) e al Ministero dell’Intelligence (MOIS), costituiscono il vertice operativo, affiancati da gruppi collegati all’IRGC nello strato intermedio, e da una base ampia di attori ideologicamente motivati al livello più basso. Questa architettura rispecchia la più ampia dottrina militare iraniana della “difesa avanzata”: la proiezione di potere attraverso proxy e asset deniabili, piuttosto che attraverso l’impiego diretto di forze regolari.

Il caso del gruppo CyberAv3ngers è paradigmatico. Al momento degli attacchi contro sistemi di controllo industriale nel settore idrico statunitense nel 2023, il gruppo si presentava come hacktivista ideologicamente motivato. Nel giro di un mese, il Dipartimento del Tesoro statunitense ha sanzionato sei funzionari dell’IRGC-CEC (Cyber-Electronic Command) per aver diretto le operazioni. Gli hacktivisti erano agenti statali fin dall’inizio.

Il pattern è stato confermato a scala più ampia dopo l’operazione militare congiunta USA-Israele del 28 febbraio 2026 contro l’Iran. Nel giro di ore, oltre 60 gruppi hacktivisti filo-iraniani si sono mobilitati, formando una struttura coordinata denominata “Electronic Operations Room”. Come documentato dal Threat Brief di Unit 42 di marzo 2026, un’analisi di DomainTools Investigations ha descritto le attività attribuite ai tre principali gruppi operativi iraniani, Homeland Justice, Karma/KarmaBelow80 e Handala Hack, come “un unico ecosistema di influenza informatica coordinata” allineato al MOIS, con persona che “funzionano come veneer operativi intercambiabili applicati a una capacità sottostante coerente”. Non tre gruppi distinti: una sola struttura con tre maschere.

Questa architettura distribuita ha dimostrato una resilienza notevole. Anche dopo che il quartier generale della Cyber Warfare dell’IRGC a Teheran è stato bombardato nel corso del conflitto, i proxy e gli hacktivisti filo-iraniani hanno continuato a operare con efficacia. La decentralizzazione non è un limite organizzativo: è una scelta dottrinale, in linea con la “difesa a mosaico”, che progetta la resilienza contro gli attacchi decapitanti attraverso la distribuzione strutturale delle capacità. Resecurity ha documentato la formazione dell’”Islamic Resilience Cyber Axis“, una coalizione di gruppi coordinati attraverso canali Telegram e forum del dark web, tra cui Cyber Islamic Resistance, Fatimion Cyber Team, Cyber Fattah, DieNet e Sylhet Gang.

Il caso Stryker: la guerra che entra in sala operatoria

L’11 marzo 2026, alle 3:30 del mattino (ora della costa est degli Stati Uniti), il gruppo Handala, persona hacktivista operata da Void Manticore, il principale strumento offensivo cibernetico del MOIS iraniano, ha colpito Stryker Corporation, colosso della tecnologia medicale con sede a Kalamazoo, Michigan. L’attacco non ha impiegato malware nel senso classico del termine: i threat actor hanno compromesso le credenziali amministrative dell’ambiente Microsoft Intune di Stryker e hanno sfruttato la funzione nativa di remote wipe della piattaforma per cancellare in remoto oltre 200.000 dispositivi, tra server, laptop e smartphone, in 79 Paesi, rendendo inutilizzabili gli endpoint nel giro di minuti. Migliaia di dipendenti hanno assistito in tempo reale alla cancellazione dei propri device aziendali e personali.

Come documentato da KrebsOnSecurity, Stryker ha confermato una “disruption globale della propria rete Microsoft” e ha avviato procedure di business continuity, isolando i sistemi e coinvolgendo il team di incident response Unit 42 di Palo Alto Networks, oltre all’FBI, alla CISA, al White House National Cyber Director e all’HHS. L’indagine ha successivamente identificato un file malevolo utilizzato per eseguire comandi nascondendo l’attività ai sistemi di rilevamento, confermato però come privo di capacità di propagazione interna o esterna.

L’impatto è stato immediato e concreto. Negli ospedali del Maryland, il sistema LIFENET di Stryker per la trasmissione di elettrocardiogrammi è risultato “non funzionale nella maggior parte dello Stato”, costringendo i clinici a ricorrere a consulto radio verbale. Alcune chirurgie sono state cancellate per indisponibilità degli impianti Stryker. Il Dipartimento di Giustizia statunitense ha confermato, in un affidavit contro gli hacker iraniani, che l’attacco “ha avuto un impatto diretto sui servizi di emergenza medica e sugli ospedali nel Maryland”. Stryker ha comunicato alla SEC che l’incidente ha avuto un impatto materiale sui risultati del primo trimestre 2026.

La motivazione dichiarata da Handala era geopolitica: l’attacco è stato presentato come ritorsione per un attacco missilistico statunitense su una scuola elementare iraniana, e come risposta alla percezione di Stryker come “azienda a radici sioniste”, in ragione dell’acquisizione, nel 2019, della società israeliana OrthoSpace. Stryker non produce armamenti, non opera nel settore della difesa e non ha alcun ruolo diretto nel conflitto. È nel mirino perché americana, perché opera in settori rilevanti per la tenuta sociale e perché colpirla produce effetti dimostrativi che travalicano il danno tecnico. Il bersaglio è simbolico quanto strategico.

Il problema dell’attribuzione: una crisi strutturale

Il nodo più critico dell’intero fenomeno è l’attribuzione. Non si tratta di una difficoltà tecnica destinata a essere risolta con strumenti migliori: è una crisi strutturale, resa tale per disegno.

L’elevata soglia giuridica necessaria per attribuire la condotta di attori non statali a uno Stato significa che Russia, Iran e altri beneficiari evadono spesso la responsabilità per le operazioni dei propri proxy nell’ambito dei tradizionali framework di responsabilità statale internazionale. Il diritto internazionale è stato costruito pensando agli Stati come attori unitari, con confini definiti di competenza e accountability. I cyber proxy lo sfruttano sistematicamente, operando in uno spazio giuridico che non prevede forme equivalenti a quelle previste per i mercenari convenzionali o i combattenti stranieri.

Sul piano tecnico, i gruppi utilizzano infrastrutture condivise, si scambiano strumenti, adottano le stesse tecniche degli attori criminali convenzionali e, soprattutto, rivendicano o negano selettivamente la paternità delle operazioni a seconda della convenienza strategica del momento. Come ha documentato Lawfare in un’analisi approfondita, i servizi di intelligence russi hanno creato proprie false persona hacktiviste, tra cui XakNet, Solntsepek e Cyber Army of Russia Reborn, per nascondere le proprie operazioni cibernetiche dirette dietro il velo dell’hacktivismo.

Il Global Cybersecurity Outlook 2026 del World Economic Forum ha rilevato che il 91% delle organizzazioni con più di 100.000 dipendenti ha modificato la propria strategia di cybersicurezza in risposta alla volatilità geopolitica, e che il 64% include oggi gli attacchi informatici con motivazione geopolitica, come la disruption di infrastrutture critiche o lo spionaggio, nella propria strategia complessiva di gestione del rischio.

Le aziende occidentali nel mirino geopolitico

Il caso Stryker non è isolato: è il caso più documentato di una tendenza strutturale. Le imprese private, anche quelle lontane dai settori tradizionalmente sensibili, sono diventate obiettivi geopolitici per ragioni che non hanno nulla a che fare con le loro vulnerabilità tecniche intrinseche o con il valore dei loro dati.

Come sottolinea il World Economic Forum, le industrie high-tech, anche quelle al di fuori della zona di conflitto attiva, sono nel mirino, poiché la distanza geografica non offre alcuna protezione. Bersagliare le organizzazioni private consente agli attori statali di indebolire i rivali indirettamente senza innescare un’immediata escalation politica: il costo del conflitto viene scaricato sul settore privato, mentre lo Stato mantiene la negazione plausibile.

Nel 2026, la distinzione tra sicurezza nazionale e sicurezza aziendale continua a erodersi. Le organizzazioni private giocano sempre più un ruolo nella difesa degli interessi nazionali, che lo vogliano o no. Le tensioni geopolitiche definiscono le decisioni di targeting, i tempi delle campagne e l’intensità operativa. Organizzazioni attive in settori o regioni sensibili, o semplicemente percepite come simbolicamente rappresentative di un Paese avversario, si trovano ad affrontare un rischio elevato sulla base del contesto geopolitico piuttosto che delle proprie azioni specifiche.

Questo implica una trasformazione profonda nel modo in cui le aziende devono concepire la propria esposizione al rischio. Come osserva il WEF, ogni Chief Information Security Officer (CISO) è diventato, di fatto, un attore geopolitico: non perché lo abbia scelto, ma perché il contesto lo ha reso tale.

Cosa fare: verso una resilienza consapevole

Di fronte a uno scenario così complesso, la risposta difensiva non può essere esclusivamente tecnica. Occorre integrare l’analisi geopolitica nel processo di risk management, un cambiamento di paradigma che va ben oltre l’aggiornamento dei sistemi di rilevamento.

Sul piano operativo, le raccomandazioni convergono su alcuni principi fondamentali. Il primo è comprendere la propria posizione nel panorama geopolitico globale: quali governi potrebbero avere interesse a colpire la propria organizzazione, in quale scenario e con quale obiettivo simbolico o strategico. Il secondo è adottare architetture zero-trust che non presuppongano l’integrità di alcuna componente della catena di fornitura, comprese le piattaforme di gestione dei dispositivi: il caso Stryker ha dimostrato che uno strumento legittimo di IT management può essere trasformato in un’arma. Il terzo è investire in threat intelligence contestualizzata, capace di distinguere l’opportunismo criminale dalle campagne state-aligned con logiche proprie. Il quarto è partecipare attivamente ai meccanismi di condivisione delle informazioni tra settori e tra Paesi.

Sul piano normativo, il lavoro non è meno urgente. Come conclude la Chatham House, le risposte tattiche dell’Occidente all’attività informatica dei proxy ostili devono essere sostituite da un approccio strategico che integri leve principali, amplificatori e politiche abilitanti di lungo periodo. Il diritto internazionale deve evolvere per includere la responsabilità degli Stati che tollerano i propri proxy digitali, analogamente a quanto già avviene per i mercenari convenzionali e i combattenti stranieri in zona di guerra.

Sul tema, vale la pena leggere l’analisi della guerra ibrida e difesa integrata NATO pubblicata su ICT Security Magazine, che delinea il quadro dottrinale entro cui si inserisce questo tipo di minacce e le risposte istituzionali in corso di definizione.

Conclusione: cyber mercenari, la guerra senza fronti

I cyber mercenari e gli hacktivisti allineati agli Stati non sono un’anomalia del paesaggio digitale contemporaneo. Sono il suo volto più coerente con la realtà geopolitica: rappresentano la risposta razionale di potenze che vogliono proiettare capacità offensive senza assumersi la responsabilità formale delle proprie azioni, in un dominio, il cyberspazio, che ancora non dispone di un diritto internazionale cogente per governarle.

Il confine tra guerra e pace, tra operazione militare e crimine informatico, tra attore statale e mercenario digitale, è diventato una zona di attrito permanente. In questo spazio operano Killnet e Black Skills, Handala e il suo ecosistema MOIS, IT Army of Russia e NoName057(16): non come fenomeni separati, ma come manifestazioni diverse di una stessa logica strategica, quella dell’ambiguità come arma.

Per le organizzazioni occidentali, la lezione è scomoda ma necessaria: in un conflitto ibrido, non esistono osservatori neutrali. Esistono bersagli che non lo sanno ancora. La consapevolezza di questa condizione è il primo passo, indispensabile anche se non sufficiente, verso una resilienza all’altezza della complessità del presente.

https://www.ictsecuritymagazine.com/articoli/cyber-mercenari/

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

---

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

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

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

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

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

Il vero obiettivo: le credenziali degli sviluppatori

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

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

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

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

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

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

Continuità con le campagne Shai-Hulud precedenti

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

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

---

---

---

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