Spcnet.it

2026-05-11 12:12:11

Quando i prompt diventano shell: vulnerabilità RCE negli AI agent framework

Gli agenti AI hanno cambiato radicalmente il modello di minaccia delle applicazioni basate su LLM. Finché un modello si limita a generare testo, le vulnerabilità rimangono nel dominio del contenuto. Ma non appena lo si dota di plugin (o tool) — lettura di file, query su database, esecuzione di script — il perimetro si espande. Una prompt injection non è più un problema di risposta inappropriata: può diventare un primitivo di esecuzione di codice arbitrario.

Il team di Microsoft Defender Security Research ha pubblicato un’analisi dettagliata di due vulnerabilità critiche scoperte in Semantic Kernel, il framework open source di Microsoft per la costruzione di agenti AI. Entrambe le vulnerabilità — già corrette — avrebbero consentito a un attaccante di ottenere RCE (Remote Code Execution) sul sistema che eseguiva l’agente, partendo semplicemente da un prompt malevolo.

Il problema di fondo: i framework AI si fidano troppo dell’output del modello

I framework come Semantic Kernel, LangChain e CrewAI agiscono come “sistema operativo” per gli agenti AI: astraggono l’orchestrazione del modello, gestiscono il routing verso i plugin e traducono il linguaggio naturale in chiamate a funzione strutturate. Questa convenienza ha un costo nascosto: ogni vulnerabilità nel modo in cui il framework mappa l’output del modello verso i tool di sistema porta un rischio sistemico.

Il modello AI stesso non è il problema — si comporta esattamente come progettato, parsando il linguaggio naturale in schemi di tool calling. Il problema sta nel fatto che il framework e i tool si fidano ciecamente dei dati così ottenuti.

CVE-2026-26030: In-Memory Vector Store e la pericolosità di eval()

La prima vulnerabilità riguarda il Search Plugin di Semantic Kernel quando usa l’In-Memory Vector Store con la configurazione predefinita.

Lo scenario di attacco richiede due condizioni:

1. L’attaccante deve avere un vettore di prompt injection — ovvero la capacità di influenzare gli input dell’agente
2. L’agente deve usare il Search Plugin con l’In-Memory Vector Store come backend

Radice tecnica del problema

La funzione di filtro predefinita dell’In-Memory Vector Store è implementata come espressione lambda Python eseguita tramite eval(). Per una ricerca tipica come “Find hotels in Paris”, il filtro generato è:

new_filter = "lambda x: x.city == 'Paris'"

Il parametro kwargs[param.name] — il valore di city — è controllato dall’output del modello AI, senza alcuna sanitizzazione. È un classico injection sink. Chiudendo la stringa e aggiungendo codice Python arbitrario, l’attaccante può trasformare una semplice query in payload eseguibile.

Il tentativo di mitigazione con blocklist — e il suo fallimento

I developer di Semantic Kernel avevano anticipato il rischio e implementato una blocklist che parsava il filtro in un Abstract Syntax Tree (AST) prima dell’esecuzione. Il validator:

• Permetteva solo espressioni lambda
• Rifiutava import e definizioni di classi
• Cercava identificatori pericolosi (eval, exec, open, __import__…)
• Eseguiva il codice in un ambiente ristretto con __builtins__ svuotati

I ricercatori hanno trovato un bypass completo. Il payload di exploit sfruttava quattro debolezze architetturali della blocklist:

1. Nomi mancanti nella blocklist: attributi come __name__, load_module, system e la classe BuiltinImporter non erano presenti nella lista nera
2. Il check strutturale passava: il payload era avvolto in una lambda valida, quindi isinstance(tree.body, ast.Lambda) restituiva True
3. __builtins__ vuoto era irrilevante: il payload partiva da tuple(), che esiste indipendentemente dall’ambiente dei builtin, e risaliva la gerarchia dei tipi Python per raggiungere funzionalità pericolose senza mai chiamare una builtin direttamente
4. Nessun controllo su ast.Subscript: anche se un nome bloccato fosse stato necessario, si sarebbe potuto accedere con notazione bracket (obj['__class__'] invece di obj.__class__), creando un nodo ast.Subscript ignorato dalla validazione

Il risultato pratico: un singolo prompt malevolo era sufficiente per lanciare calc.exe sul sistema che eseguiva l’agente, senza exploit del browser, allegati malevoli o memory corruption.

La lezione generale: le blocklist nei linguaggi dinamici sono fragili

Python (e linguaggi dinamici in generale) offre troppa flessibilità per essere gestita efficacemente con una lista nera. La gerarchia di classi del runtime, la riflessione, i dunders e le notazioni alternative rendono qualsiasi blocklist incompleta per definizione.

CVE-2026-25592: scrittura arbitraria di file tramite SessionsPythonPlugin

La seconda vulnerabilità riguarda il SessionsPythonPlugin, che permette agli agenti di eseguire codice Python in sessioni di Azure Container Apps. Il plugin accetta un nome di file come parametro controllato dall’LLM — senza validazione del percorso — e lo usa per scrivere file nel filesystem del container. Attraverso path traversal (es. ../../etc/cron.d/payload), un attaccante con accesso al vettore di prompt injection potrebbe scrivere file arbitrari in posizioni sensibili del sistema.

La mitigazione applicata da Semantic Kernel

Dopo la responsible disclosure al MSRC, il team di Semantic Kernel ha implementato una correzione multilivello per CVE-2026-26030, sostituendo la blocklist con un approccio allowlist a quattro strati:

1. Allowlist dei tipi AST: solo costrutti sicuri sono permessi — comparazioni, logica booleana, aritmetica, letterali
2. Allowlist delle chiamate a funzione: anche i nodi di chiamata AST permessi vengono verificati per assicurarsi che invochino solo funzioni sicure
3. Blocklist degli attributi pericolosi: traversata della gerarchia di classi bloccata esplicitamente (__class__, __subclasses__)
4. Restrizione sui nodi Name: solo il parametro della lambda (es. x) è accettabile come identificatore; riferimenti a os, eval, type e simili vengono rifiutati

Come sapere se si è vulnerabili

Si è esposti a CVE-2026-26030 se:

• Si usa il pacchetto Python semantic-kernel
• La versione del framework è precedente alla 1.39.4
• L’agente usa l’In-Memory Vector Store con funzionalità di filtro abilitata come backend per il Search Plugin

Per verificare la versione installata:

pip show semantic-kernel

Per aggiornare:

pip install --upgrade semantic-kernel

Raccomandazioni per gli sviluppatori di agenti AI

Questa ricerca offre lezioni importanti per chiunque stia costruendo applicazioni con agenti AI:

• Non trattare l’output del modello come dati fidati: qualsiasi valore che passa dal modello AI a un tool deve essere trattato come input non fidato, validato e sanitizzato come si farebbe con input da un utente esterno
• Preferire allowlist alle blocklist: nelle valutazioni di codice dinamico, le blocklist sono intrinsecamente incomplete. Un allowlist di costrutti permessi è molto più robusto
• Evitare eval() con input derivati dall’LLM: se il requisito è eseguire espressioni dinamiche, usare AST parsing con validazione rigorosa o, meglio, un motore di espressioni dedicato con capacità limitate
• Applicare il principio del minimo privilegio: i plugin degli agenti dovrebbero avere solo le autorizzazioni strettamente necessarie; un plugin che scrive file non dovrebbe mai avere accesso all’intero filesystem
• Monitorare i vettori di prompt injection: qualsiasi fonte esterna che l’agente legge (email, documenti, pagine web, risultati di ricerca) è un potenziale vettore di attacco
• Tenere aggiornati i framework: le vulnerabilità nei framework AI si stanno moltiplicando rapidamente; aggiornare regolarmente e seguire i bollettini di sicurezza dei vendor è essenziale

Un challenge per mettersi alla prova

Microsoft ha anche pubblicato un CTF challenge interattivo che permette di testare l’exploit su un agente Semantic Kernel di esempio in modo sicuro e controllato. È un ottimo modo per capire concretamente il vettore di attacco senza rischiare sistemi reali.

Conclusione

La transizione degli agenti AI da generatori di testo a sistemi che operano attivamente sull’infrastruttura richiede un cambio di mentalità nella sicurezza. Le vulnerabilità come CVE-2026-26030 e CVE-2026-25592 mostrano che i rischi sono reali e concreti: un prompt malevolo può diventare RCE. Aggiornare Semantic Kernel alla versione 1.39.4 o superiore è la priorità immediata; rivedere l’architettura dei propri agenti alla luce del principio di minimo privilegio è il passo successivo.

Microsoft ha annunciato una serie di ricerche simili su altri framework AI (LangChain, CrewAI e altri) — ulteriori pubblicazioni sono previste nelle prossime settimane.

Fonte: When prompts become shells: RCE vulnerabilities in AI agent frameworks — Microsoft Defender Security Research Team (7 maggio 2026)

When prompts become shells: RCE vulnerabilities in AI agent frameworks | Microsoft Security Blog

New research exposes how prompt injection in AI agent frameworks can lead to remote code execution. Learn how these vulnerabilities work, what’s impacted, and how to secure your agents.

^{Microsoft Defender Security Research Team (Microsoft Security Blog)}

(in)sicurezza digitale

2026-05-11 12:17:30

DAEMON Tools compromesso: supply chain attack dal sito ufficiale con backdoor QUIC RAT e 100+ paesi colpiti

Si parla di:
Toggle

Dal 8 aprile 2026, chiunque abbia scaricato DAEMON Tools dal sito ufficiale ha potuto ricevere un installer trojanizzato — firmato digitalmente dal produttore — che installa silenziosamente una backdoor con capacità di comunicazione su sette protocolli diversi, tra cui QUIC e HTTP/3. Kaspersky ha svelato l’operazione a maggio: migliaia di tentativi di infezione in oltre 100 paesi, con targeting chirurgico su enti governativi, scientifici e industriali in una seconda fase. Sullo sfondo, i ricercatori puntano verso un attore di lingua cinese.

Il vettore d’attacco: il sito ufficiale come arma

DAEMON Tools è uno dei software di emulazione dischi più diffusi al mondo, con decine di milioni di utenti. La sua ubiquità lo rende un bersaglio ideale per un attacco supply chain: compromettere il sito ufficiale significa trasformare uno strumento di fiducia in un vettore di distribuzione malware su scala globale.

Secondo l’analisi pubblicata da Kaspersky su Securelist, i ricercatori hanno identificato che le versioni da 12.5.0.2421 a 12.5.0.2434 di DAEMON Tools distribuite dal sito ufficiale del produttore — AVB Disc Soft — contenevano componenti binari modificati con codice malevolo. La finestra di compromissione è iniziata almeno dall’8 aprile 2026 e l’attacco era ancora attivo al momento della divulgazione pubblica avvenuta intorno al 6 maggio 2026.

Anatomia tecnica: tre binari compromessi, un’unica catena d’attacco

Gli attaccanti hanno manomesso tre componenti specifici all’interno del pacchetto di installazione:

• DTHelper.exe — componente helper principale del software
• DiscSoftBusServiceLite.exe — servizio di sistema lanciato all’avvio del sistema
• DTShellHlp.exe — helper per le funzioni di shell integration

L’elemento più insidioso è che tutti e tre i file risultano ancora firmati digitalmente con certificati validi di AVB Disc Soft. Questo significa che i controlli di firma digitale standard — inclusi quelli di Windows SmartScreen e la maggior parte degli antivirus basati su reputazione — non avrebbero segnalato nulla di anomalo al momento dell’installazione. Solo una soluzione EDR con analisi comportamentale avanzata avrebbe potuto identificare l’attività malevola in fase di esecuzione.

Ogni volta che uno di questi binari viene lanciato — e dato che DiscSoftBusServiceLite.exe è un servizio Windows, ciò avviene automaticamente ad ogni avvio del sistema — la backdoor si attiva e stabilisce comunicazione con il server C2.

Il payload di prima fase: information stealer silenzioso

Nella maggior parte dei sistemi infetti, l’attivazione della backdoor comporta innanzitutto l’esecuzione di un info-stealer di prima fase che raccoglie i seguenti dati di profilazione del sistema:

• Indirizzo MAC e hostname della macchina
• Software installato ed elenco processi in esecuzione
• Configurazione di rete (interfacce, IP, gateway)
• Locale di sistema e impostazioni geografiche

Questi dati vengono trasmessi al server C2 e con ogni probabilità utilizzati per selezione e triage delle vittime: non tutti i sistemi infetti ricevono il payload avanzato. Kaspersky ha rilevato che solo un numero limitato di macchine — stimato in una dozzina di sistemi su migliaia di infezioni — ha ricevuto il secondo stage, il che indica targeting altamente selettivo.

QUIC RAT: la backdoor di secondo livello

I sistemi selezionati ricevono QUIC RAT, un impianto avanzato che prende il nome dal protocollo di trasporto di Google su cui si basa come canale C2 preferenziale. La caratteristica tecnica distintiva di QUIC RAT è la sua resilienza nei canali di comunicazione: il malware supporta ben sette protocolli C2 distinti, da usare in modo adattivo a seconda dell’ambiente della vittima:

• HTTP e HTTPS — per ambienti con proxy web standard
• UDP e TCP raw — per connessioni dirette a bassa latenza
• WSS (WebSocket Secure) — per bypassare firewall che bloccano connessioni non-HTTP
• QUIC (HTTP/3 su UDP) — il protocollo eponimo, difficile da ispezionare con DPI tradizionale
• DNS — per ambienti con filtering aggressivo, usando richieste DNS come canale covert

Questa flessibilità rende QUIC RAT particolarmente difficile da bloccare con soluzioni di network security tradizionali: anche in ambienti con firewalling aggressivo, il malware può adattarsi dinamicamente al protocollo consentito.

Sul fronte delle funzionalità offensive, QUIC RAT è capace di iniettare payload malevoli nei processi notepad.exe e conhost.exe — due processi legittimi di Windows particolarmente adatti al process injection per la loro ubiquità e bassa visibilità in ambienti non monitorati.

La scala dell’operazione

A partire dall’inizio di aprile 2026, Kaspersky ha rilevato diverse migliaia di tentativi di installazione di payload malevoli attraverso DAEMON Tools compromesso, con vittime distribuite in oltre 100 paesi e territori. La distribuzione geografica è significativa: il maggior numero di infezioni è stato rilevato in Russia, Brasile, Turchia, Spagna, Germania, Francia, Italia e Cina.

La composizione delle vittime rivela la natura dell’operazione: circa il 90% dei sistemi infetti appartiene a utenti privati, mentre il restante 10% corrisponde a sistemi aziendali e organizzativi. È plausibile che la grande massa di utenti privati funzionasse come copertura e rumore di fondo, mentre gli attaccanti erano in realtà interessati alla percentuale aziendale — che in termini assoluti, su migliaia di infezioni, rappresenta comunque centinaia di potenziali target di interesse.

Kaspersky ha specificato che tra le organizzazioni colpite dalla seconda fase con QUIC RAT figurano enti governativi, istituti di ricerca scientifica e aziende manifatturiere.

Attribuzione: tracce verso un attore sinofono

Kaspersky non attribuisce formalmente l’attacco a un gruppo specifico, ma i ricercatori hanno rilevato stringhe in lingua cinese nel payload di prima fase. Questo, combinato con la sofisticazione operativa dell’attacco, la selezione dei target di seconda fase e la natura delle vittime prioritizzate, suggerisce un attore di lingua cinese — potenzialmente un gruppo APT state-sponsored, anche se al momento non è possibile escludere un cybercriminale con capacità avanzate.

Il pattern di targeting selettivo e il profilo delle vittime di alto valore sono però più coerenti con operazioni di intelligence che con motivazioni puramente economiche.

Indicatori di compromissione (IoC)

# Versioni DAEMON Tools compromesse
Versioni affette: 12.5.0.2421 — 12.5.0.2434

# Binari manomessi (firmati da AVB Disc Soft)
DTHelper.exe
DiscSoftBusServiceLite.exe
DTShellHlp.exe

# Protocolli C2 usati da QUIC RAT
HTTP, HTTPS, UDP, TCP, WSS (WebSocket Secure), QUIC/HTTP3, DNS

# Tecniche MITRE ATT&CK
T1195.002 — Supply Chain Compromise: Software Supply Chain
T1553.002 — Subvert Trust Controls: Code Signing (signed malicious binaries)
T1071     — Application Layer Protocol (multi-protocol C2)
T1572     — Protocol Tunneling (QUIC/DNS channels)
T1055     — Process Injection (notepad.exe / conhost.exe)
T1082     — System Information Discovery (first-stage profiling)
T1018     — Remote System Discovery

# Nota: IoC hash completi disponibili su Securelist
# https://securelist.com/daemon-tools-backdoor/

Come verificare se si è stati colpiti

Chi ha installato o aggiornato DAEMON Tools tra aprile e inizio maggio 2026 dovrebbe verificare urgentemente la versione installata. Se rientra nell’intervallo 12.5.0.2421-12.5.0.2434, è necessario procedere come segue: disinstallare immediatamente DAEMON Tools e aggiornare all’ultima versione disponibile dal sito ufficiale (già corretta al momento della disclosure). Eseguire una scansione completa con una soluzione EDR aggiornata, monitorando in particolare attività anomale di notepad.exe e conhost.exe. Verificare la presenza di connessioni insolite su porta UDP 443 (QUIC) o traffico DNS anomalo verso domini non riconosciuti. Controllare il registro di sistema per servizi sospetti aggiunti da DiscSoftBusServiceLite.exe o varianti.

Il report tecnico completo di Kaspersky con hash SHA256 e IoC di rete è disponibile su Securelist. La press release ufficiale è su kaspersky.com.

Securelist | Kaspersky’s threat research and reports

The Securelist blog houses Kaspersky’s threat intelligence reports, malware research, APT analysis and statistics

^{Kaspersky (Securelist)}

m0nt4lb4n0

2026-05-06 06:09:14

2° Meeting nazionale TWC Italia

Inizia: Sabato Giugno 13, 2026 @ 12:00 AM GMT+02:00 (Europe/Rome)

Finisce: Domenica Giugno 14, 2026 @ 12:00 AM GMT+02:00 (Europe/Rome)

Incontriamoci. Confrontiamoci. Organizziamoci.

🌍 LSA100Celle - Roma

📍13 e 14 giugno ci vediamo a #Roma per il secondo Meeting nazionale di Tech Workers Coalition Italia. Un'occasione per discutere delle criticità del settore tech italiano e globale e mettere in rete le pratiche di mobilitazione.Un grande log out nazionale per costruire l'alternativa possibile nei nostri luoghi di lavoro. Non lasciamoci deformare dalla tecnologia.

Sostieni il meeting su OpenCollective e segui tutti gli aggiornamenti sul programma sul nostro sito.

Instagram

Create an account or log in to Instagram - Share what you're into with the people who get you.

^Instagram

(in)sicurezza digitale

2026-05-10 10:07:02

Silver Fox lancia ABCDoor: spear phishing con loader Rust personalizzato contro India e Russia, nuova backdoor Python in campo

Tra dicembre 2025 e febbraio 2026, il gruppo APT di matrice cinese noto come Silver Fox ha lanciato due ondate coordinate di spear phishing contro organizzazioni in India e Russia, sfruttando esche a tema fiscale costruite ad hoc per ciascun paese. Il vettore tecnico è un loader Rust modificato — una versione bespoke del framework open source RustSL — che distribuisce ValleyRAT (aka Winos 4.0) insieme a una backdoor Python finora inedito, denominato ABCDoor. La ricerca è stata pubblicata da Kaspersky Securelist e ripresa da The Hacker News il 4 maggio 2026. Più di 1.600 email di phishing sono state registrate tra inizio gennaio e inizio febbraio, con organizzazioni impattate nei settori industriale, consulenza, retail e trasporti.

Il profilo di Silver Fox: doppio binario tra cybercrime e spionaggio

Silver Fox è un gruppo APT cinese attivo almeno dal 2024, documentato inizialmente per campagne contro obiettivi in Cina, poi espanso verso Taiwan, Giappone, India e Russia. Secondo l’analisi di S2W, il gruppo ha sviluppato un «dual-track operational model» che conduce simultaneamente attività opportunistiche su larga scala — tipiche del cybercrime finanziario — e operazioni di spionaggio più mirate. L’adozione di lure personalizzate per ciascun paese bersaglio, con riferimenti puntuali ai sistemi fiscali locali, indica un livello di intelligence preliminare coerente con un’operazione state-sponsored o comunque sostenuta da risorse significative.

La catena d’attacco: phishing, RustSL, ValleyRAT, ABCDoor

Fase 1 — Delivery via phishing fiscale

Le email di phishing impersonano comunicazioni ufficiali dell’Income Tax Department of India (dicembre 2025) e successivamente dell’equivalente russo (gennaio 2026). Il messaggio contiene un PDF allegato con due link cliccabili che reindirizzano al download di un archivio ZIP o RAR ospitato su abc.haijing88[.]com. All’interno dell’archivio si trova un eseguibile che si maschera da PDF. In alcune varianti della campagna di dicembre, il codice malevolo è stato incorporato direttamente nell’allegato email, saltando il redirect esterno.

Fase 2 — RustSL loader: geofencing e anti-analysis

L’eseguibile è una versione modificata di RustSL, un framework open source per shellcode loader e bypass degli antivirus scritto in Rust. Silver Fox ha personalizzato il codice sorgente pubblicamente disponibile su GitHub, aggiungendo funzionalità non presenti nell’originale:

• Geofencing per paese: la versione originale di RustSL supporta solo la Cina come paese bersaglio; la variante Silver Fox estende la lista a India, Indonesia, Sud Africa, Russia e Cambogia (con versioni successive che aggiungono il Giappone). Il loader verifica la geolocalizzazione prima di procedere, abortendo l’esecuzione in caso di mismatch.
• Rilevamento di VM e sandbox: controlli ambientali standard per ostacolare l’analisi dinamica in ambienti di ricerca.
• Phantom Persistence: una variante del loader utilizza una tecnica di persistenza documentata per la prima volta nel giugno 2025 come «Phantom Persistence». Il meccanismo intercetta il segnale di shutdown del sistema, blocca la normale sequenza di spegnimento e forza un riavvio simulando un aggiornamento applicativo. Al successivo avvio dell’OS, il loader viene eseguito automaticamente.

# Infrastruttura C2 identificata
abc.haijing88[.]com          — hosting archivi payload
login-module.dll_bin         — componente core C2 di ValleyRAT
# Country list RustSL personalizzato (pre-19 gennaio 2026)
IN, ID, ZA, RU, KH
# Versioni successive aggiungono:
JP

Fase 3 — ValleyRAT (Winos 4.0)

Il payload crittografato scompattato da RustSL è ValleyRAT, noto anche come Winos 4.0, un framework malware modulare già utilizzato da Silver Fox in campagne precedenti. Il componente core, denominato login-module.dll_bin, gestisce le comunicazioni C2, l’esecuzione di comandi remoti e il recupero ed esecuzione di moduli aggiuntivi. È su questo layer modulare che viene distribuito ABCDoor.

Fase 4 — ABCDoor: la nuova backdoor Python

ABCDoor è una backdoor Python finora inedita, presente nell’arsenale di Silver Fox dal 19 dicembre 2024 e utilizzato in attacchi a partire da febbraio-marzo 2025. Viene distribuita come modulo personalizzato di ValleyRAT, dopo un secondo controllo di geofencing che filtra ulteriormente il target. Le capacità operative documentate da Kaspersky includono:

• Persistenza e aggiornamento/rimozione autonomo del backdoor
• Cattura di screenshot
• Controllo remoto di mouse e tastiera
• Operazioni sul file system (lettura, scrittura, esecuzione)
• Gestione dei processi di sistema
• Esfiltrazione del contenuto degli appunti (clipboard)
• Comunicazione C2 via HTTPS con server esterno

In varianti più recenti, osservate a partire da novembre 2025, ABCDoor viene distribuito anche tramite un loader JavaScript distribuito all’interno di archivi SFX (self-extracting) contenuti in ZIP allegati a email di phishing — un vettore alternativo che non richiede RustSL come intermediario.

Distribuzione geografica e settori impattati

Il maggior numero di attacchi è stato rilevato in India, Russia e Indonesia, seguiti da Sud Africa e Giappone. I settori più colpiti nelle ondate di gennaio-febbraio 2026 sono stati industriale, consulenza, retail e trasporti. La scelta di bersagliare contemporaneamente India e Russia — paesi con rapporti complessi con la Cina sia a livello diplomatico che commerciale — suggerisce un obiettivo di intelligence economica e politica piuttosto che un’operazione puramente finanziaria.

Connessione con campagne precedenti

Silver Fox aveva già utilizzato ValleyRAT in campagne precedenti, tipicamente contro obiettivi in Asia orientale. L’introduzione di RustSL come loader — con personalizzazioni sofisticate del codice sorgente open source — e la comparsa di ABCDoor come modulo aggiuntivo indicano un’evoluzione significativa delle capacità tecniche del gruppo. La tecnica di Phantom Persistence, che sfrutta il meccanismo di Windows per gli aggiornamenti che richiedono riavvio, è particolarmente interessante per la sua capacità di sopravvivere ai controlli di startup standard.

IoC e indicatori di compromissione

# Dominio C2 principale
abc.haijing88[.]com
# File chiave da monitorare
login-module.dll_bin        — componente core ValleyRAT C2
RustSL variants             — loader con geofencing integrato
# Pattern comportamentali (Phantom Persistence)
- Intercettazione segnale WM_QUERYENDSESSION/WM_ENDSESSION
- Registrazione come "pending file rename operation" al riavvio
- Esecuzione al boot mascherata da aggiornamento applicativo
# Vettore email
- Mittente che impersona Income Tax Department (India) o equivalente russo
- Allegato PDF con link a haijing88[.]com
- Archivio ZIP/RAR con eseguibile che simula PDF

Due righe per i difensori

• Bloccare il dominio abc.haijing88[.]com nei proxy web e nei firewall di uscita.
• Monitorare il comportamento di shutdown: processi che intercettano WM_QUERYENDSESSION o modificano PendingFileRenameOperations nel registry durante lo shutdown sono indicatori forti di Phantom Persistence.
• Email gateway: filtrare allegati PDF con link a domini registrati di recente e archivi SFX annidati in ZIP. Le esche fiscali sono stagionali ma prevedibili.
• EDR con visibilità sulle tecniche LotL: ABCDoor usa funzioni di sistema standard per operazioni di file system e controllo remoto; rilevarlo richiede behavioral analytics e non solo firma.
• Sandboxing con geolocalizzazione autentica: il geofencing di RustSL aborta in ambienti non corrispondenti ai paesi target. Sandbox configurate con IP di geolocalizzazione neutri potrebbero non triggerare il payload. Usare VPN con IP indiano, russo o indonesiano per l’analisi dinamica.

La campagna Silver Fox conferma una tendenza in atto: i gruppi APT cinesi stanno diversificando geograficamente i propri bersagli ben oltre i tradizionali obiettivi in Asia orientale, e stanno investendo nello sviluppo di tooling personalizzato — loader Rust bespoke, backdoor Python inediti, tecniche di persistenza innovative — che rende inefficaci le soluzioni di detection basate esclusivamente su signature statiche.

(in)sicurezza digitale

2026-05-09 17:44:54

Salt Typhoon nella PA italiana: Sistemi Informativi di IBM violata per due settimane, il cyberspionaggio cinese entra nella supply chain dello Stato

Nelle prime ore del 3 maggio 2026, la notizia di un’intrusione ai danni di Sistemi Informativi — la società romana controllata al 100% da IBM Italia — ha attraversato le redazioni in modo fulmineo. Dietro all’attacco, secondo le ricostruzioni convergenti di più fonti e con la pista ancora aperta per le autorità inquirenti, ci sarebbe probabilmente, voce poi smentita, Salt Typhoon: il gruppo APT riconducibile all’apparato di sicurezza della Repubblica Popolare Cinese, già responsabile della violazione di nove operatori telecom statunitensi tra cui AT&T e Verizon. Questa volta, però, il bersaglio non è un’infrastruttura straniera: è il cuore tecnologico della Pubblica Amministrazione italiana. Doveroso ricordare che al momento, per quanto comunicato dall’azienda e per la posizione di IBM, l’attacco ha avuto successo per Sistemi Informativi SRL, senza colpire la supply chain sensibile e strategica che adesso andremo ad analizzare. Questo significa che i sistemi IBM al di fuori di Sistemi Informativi restano non coinvolti. Ma vediamo di che perimetro stiamo parlando.

Chi è Sistemi Informativi e perché è un bersaglio critico

Fondata nel 1979 e con sede a Roma, Sistemi Informativi opera come system integrator nei segmenti più sensibili della trasformazione digitale italiana. Tra i suoi committenti figurano INPS, INAIL, diversi ministeri, banche, operatori delle telecomunicazioni, aziende del comparto energetico e numerosi soggetti impegnati nelle iniziative del Piano Nazionale di Ripresa e Resilienza, dalla sanità digitale al cloud nazionale. Con circa 800 dipendenti, la società rappresenta uno snodo critico: compromettere un solo integrator di questa portata significa, in linea di principio, ottenere visibilità su contratti pubblici, credenziali di accesso, dati di milioni di cittadini, configurazioni di rete e dipendenze applicative di enti distanti per missione e per settore.

È esattamente il tipo di superficie d’attacco che le campagne di cyberspionaggio statale ricercano da anni. Non il rumore dell’esfiltrazione massiva, ma la visibilità silenziosa su un ecosistema intero.

La timeline dell’incidente

L’intrusione sarebbe avvenuta circa due settimane prima della sua scoperta e rivelazione pubblica, fissando l’inizio della compromissione intorno alla metà di aprile 2026. Una finestra temporale coerente con il modus operandi di Salt Typhoon, che predilige la persistenza silenziosa e l’esfiltrazione progressiva dei dati all’azione rumorosa e distruttiva tipica del ransomware.

• 3 maggio 2026: la testata Repubblica.it pubblica l’anticipazione dell’attacco. Il sito ufficiale di Sistemi Informativi risulta irraggiungibile.
• Sera del 3 maggio: IBM diffonde un comunicato ufficiale confermando l’intrusione, l’attivazione dei protocolli di incident response e il coinvolgimento di specialisti interni ed esterni. I sistemi sono stati stabilizzati, i servizi ripristinati.
• 3-4 maggio: il Ministro per la Pubblica Amministrazione Paolo Zangrillo dichiara che «tutti gli attori istituzionali competenti stanno portando avanti le procedure previste dalla normativa» e che ACN ha avviato ogni azione necessaria per definire origine e impatto dell’attacco.
• 5-6 maggio 2026: la Procura Antiterrorismo di Roma, coordinata dal procuratore Francesco Lo Voi, apre un fascicolo ipotizzando il reato di accesso abusivo a sistema informatico.
• 6 maggio: IBM fornisce un comunicato aggiuntivo precisando: «Ad oggi, non riteniamo che questa attività sia attribuibile a Salt Typhoon». La pista resta però aperta per gli investigatori.

Il profilo di Salt Typhoon: alias, TTP e campagne note

Salt Typhoon — tracciato anche come OPERATOR PANDA, RedMike, UNC5807, GhostEmperor, Earth Estries (Trend Micro), UNC2286 (Mandiant) e FamousSparrow (ESET) — è un cluster di attività malevole documentato nel joint advisory AA25-239A pubblicato dalla CISA il 27 agosto 2025, sottoscritto da NSA, FBI, Department of Defense Cyber Crime Center e partner internazionali tra cui l’Italia. L’advisory riconduce il cluster a tre aziende tecnologiche cinesi ritenute fornitrici del Ministero per la Sicurezza dello Stato e dell’Esercito Popolare di Liberazione: Sichuan Juxinhe Network Technology, Beijing Huanyu Tianqiong Information Technology e Sichuan Zhixin Ruijie Network Technology.

L’attribuzione formale data l’inizio delle operazioni almeno al 2021, mentre le prime ricostruzioni dell’industria ne collocano l’attività già al 2019. I settori bersaglio privilegiati sono le telecomunicazioni, la pubblica amministrazione, i trasporti, il comparto alberghiero e la difesa. La logica operativa è quella della raccolta di intelligence di lungo periodo, non dell’estorsione finanziaria: non distruggere, ma sapere, e sapere a lungo.

Vettori d’attacco e strumenti

Il joint advisory CISA chiarisce un aspetto tecnico rilevante: Salt Typhoon non utilizza in modo sistematico falle zero-day, ma sfrutta vulnerabilità CVE pubblicamente note e già corrette dai vendor, in danno di organizzazioni che non hanno applicato gli aggiornamenti. Tra le vulnerabilità prioritariamente sfruttate:

CVE-2024-21887 / CVE-2023-46805 — Ivanti Connect Secure e Policy Secure
CVE-2024-3400              — Palo Alto Networks PAN-OS GlobalProtect
CVE-2023-20198 / CVE-2023-20273 — Cisco IOS XE
CVE-2018-0171              — Cisco IOS e IOS XE

Sul versante del payload, il gruppo ricorre a utility come JumbledPath, capace di catturare il traffico di rete su dispositivi Cisco compromessi attraverso catene di jump host, e impiega tecniche Living off the Land (LotL) in cui l’attività malevola si confonde con il traffico legittimo prodotto da strumenti già presenti sul target. In Europa, Darktrace ha documentato nell’ottobre 2025 un’intrusione contro un grande operatore telecom europeo ottenuta sfruttando CVE su Citrix NetScaler Gateway, con movimento laterale verso host Citrix VDA, mascheramento tramite SoftEther VPN e installazione del backdoor SNAPPYBEE via DLL sideloading.

Supply chain della PA: il vero punto debole strutturale

L’episodio italiano si inserisce in un pattern consolidato. Negli ultimi due anni, gli attori statali ostili hanno spostato il fuoco dai bersagli finali ai loro fornitori tecnologici. Compromettere un fornitore unico che funge da snodo per decine di clienti istituzionali è un investimento offensivo di altissima resa. La PA italiana è esposta a una concentrazione di rischio strutturale: il numero ridotto di system integrator in grado di gestire progetti di scala nazionale crea un punto di accumulo della fiducia che, se compromesso, propaga la violazione attraverso l’intera filiera senza ulteriori intrusioni dirette.

I contratti pubblici raramente prevedono requisiti di sicurezza commisurati al ruolo strategico del fornitore: clausole di security by design, audit indipendenti, threat hunting continuo, segmentazione di rete tra ambienti di clienti diversi, gestione strutturata delle identità privilegiate. Il caso Sistemi Informativi imporrà, con ogni probabilità, una revisione profonda di queste pratiche per i fornitori di soggetti essenziali e importanti ai sensi della NIS2.

NIS2 e D.Lgs. 138/2024: il primo banco di prova reale

L’incidente cade nel primo quadrimestre di piena operatività del nuovo regime di notifica degli incidenti significativi introdotto dalla NIS2, recepita con il D.Lgs. 138/2024 e pienamente vigente dal 1° gennaio 2026. I soggetti essenziali e importanti devono trasmettere al CSIRT Italia una pre-notifica entro 24 ore dall’evidenza dell’incidente, una notifica completa entro 72 ore e una relazione finale entro un mese. Il caso Sistemi Informativi è il primo banco di prova di rilievo nazionale per l’intero sistema: come vengono gestiti gli adempimenti, con quale coordinamento tra ACN, Garante e operatori, con quali tempi e con quale trasparenza diventerà un precedente operativo per il sistema.

Salt, Volt, Flax: la pressione cinese sull’Europa è sistemica

L’incidente non è un episodio isolato: è il segmento europeo di una pressione sistemica articolata su più fronti. Salt Typhoon si concentra sull’intercettazione delle comunicazioni e sulla raccolta di intelligence presso carrier e fornitori IT. Volt Typhoon mira a posizionare implant nelle infrastrutture critiche civili statunitensi in una logica di prepositioning per scenari di crisi. Flax Typhoon, sanzionato dall’OFAC, costruisce botnet di dispositivi compromessi utilizzabili a copertura di ulteriori operazioni. La sovrapposizione delle tre campagne disegna un’architettura di pressione nella quale spionaggio, sabotaggio potenziale e infrastruttura offensiva convivono e si rafforzano reciprocamente.

Indicazioni pratiche per i difensori

• Patch management aggressivo sui perimeter device: le CVE sfruttate da Salt Typhoon sono note e corrette. La finestra di esposizione si chiude solo applicando gli aggiornamenti. Priorità assoluta a Ivanti, Palo Alto PAN-OS, Cisco IOS XE.
• Network segmentation e Zero Trust: in ambienti multi-cliente come quelli degli integrator, la segmentazione rigida tra tenant è l’unico modo per contenere il movimento laterale post-compromissione.
• Threat hunting sulle appliance perimetrali: rilevare JumbledPath e tecniche LotL richiede visibilità sul traffico di rete a livello di dispositivo, non solo sugli endpoint. NetFlow, logging di sistema e behavioral analytics sono prerequisiti.
• Revisione dei contratti con fornitori strategici: includere requisiti minimi di sicurezza, diritto di audit e obblighi di incident notification con tempistiche allineate alla NIS2.
• Condivisione di threat intelligence con CSIRT Italia: segnalare tempestivamente IoC e pattern d’attacco contribuisce alla difesa collettiva del sistema-Paese.

L’attacco di Salt Typhoon a IBM Italia non si misura soltanto dalla quantità di dati eventualmente esfiltrati, che resta a oggi non quantificabile. Il suo significato è strategico: conferma che la frontiera dell’attacco si è spostata sui fornitori unici di servizi pubblici, che i vettori d’ingresso più produttivi restano le appliance perimetrali con CVE pubblicate ma non corrette, e che la persistenza silenziosa — non il ransomware — è la firma delle operazioni che contano davvero.

404 Media

2026-05-08 15:50:03

'The Biggest Student Data Privacy Disaster in History': Canvas Hack Shows the Danger of Centralized EdTech

Thursday afternoon, millions of students at thousands of universities and K-12 schools were locked out of Canvas, a piece of catch-all education technology software that has become the de facto core of many classes. ShinyHunters, a ransomware group, hacked Canvas’s parent company and apparently stole “billions” of messages and accessed more than 275 million individuals’ data, according to the hacking group. The group also locked students out of Canvas.

Later Thursday, Instructure, which makes Canvas, was able to mostly put Canvas back online; it is not clear if the company paid a ransom or not. The breach demonstrates the danger in centralizing the educational and personal data of millions of students in a single service. Canvas is essentially a portal where teachers post assignments and lectures, have discussion boards, and students can message with each other and their teachers and connect with other pieces of education tech software.

Instructure noted on an incident update page that the stolen data includes “certain personal information of users at affected organizations. That includes names, email addresses, student ID numbers, and messages among Canvas users.” Instructure also noted that it was breached twice—once on April 29 and again on Thursday.

Soon after the hack, I called up Ian Linkletter, a digital librarian specializing in emerging education tech, to talk about the implications of the breach. Linkletter has worked in education tech for 20 years and over the last few years has become known for exposing privacy concerns in Proctorio, a remote test proctoring software that rose to prominence during the early days of the COVID-19 pandemic. Linkletter was sued by Proctorio but eventually the case was dropped.

Linkletter told me the Canvas hack is “the biggest student data privacy disaster in history” in part because of its scale and the sensitive nature of what was stolen. This is my conversation with Linkletter, which has been lightly condensed.

404 Media: What do we know about the hack so far?
Linkletter: At about 1:20 PM [Pacific, Thursday], people started posting screenshots to Reddit of this breach message that they got. Some institutions were cautioning people to change their passwords if they were logged in, right now it just seems like people are in panic mode, some senior administration at schools are in meetings talking about whether they need to cancel finals next week. It’s just the implications are on everything because schools are reliant on this learning management system for everything—communications, grading, finals, everything.

In your email to me, you said you've worked in EdTech for 20 years and you said this is the biggest student data privacy disaster in history. I'm curious what sort of made you frame it that way.
I supported Blackboard [a similar piece of tech] way back in the day and I supported Canvas from about 2017 to 2022 when I worked at the University of British Columbia. And what I was there for when we switched to Canvas in 2017 was the shift from like these scrappy little self-hosted learning management system apps that would be on Canadian servers to this centralized, all eggs-in-one basket faith in a U.S. tech company. This idea that our data would be just as safe with them as it was when we had it. And because this move to the cloud happened so suddenly about 10 years ago, all of a sudden data got centralized. The only way that I can think of that this type of hack where everything went down, where so much was stolen would be if Instructure had access to everybody's data, which doesn't seem necessary. For it to be just so widespread across every customer is something that, like, [we’ve] never seen before.

Because the contents of messages got leaked, it’s really easy for phishing attacks to get customized. Like, Canvas got hacked [...] and continuing our conversation type of thing, you can get some really personal information from people. And that's also new.

I can also imagine messages between students and teachers to be pretty sensitive.
I supported instructors that used Canvas. And so I would hear these stories like, and they're on like the professor’s subreddit and stuff too, like students are telling you that people died [to explain absences]. There's personal circumstances, medical circumstances, accessibility accommodations, disputes, sexual assault allegations, like all sorts of stuff would be getting reported to the instructor using Canvas. If that information is out across hundreds of millions of people, there's a lot of harm that's going to happen.

What will you be kind of monitoring as this plays out?
My biggest concern right now is monitoring the institutional response. I feel very strongly that students should have been warned about this like days ago. And it just took this second hack where students got something in their face notifying them that really made schools respond. So I believe that students need to be warned or else they're going to get harmed. And the longer schools wait to tell students about what’s going on, even the little that they know, the more stress and chaos and potential risk to student privacy and safety is at stake.

He got sued for sharing public YouTube videos; nightmare ended in settlement

Librarian vows to stop invasive ed tech after ending lawsuit with Proctorio.

^{Ashley Belanger (Ars Technica)}