(in)sicurezza digitale

2026-05-27 07:47:40

CVE-2026-5426: zero-day in KnowledgeDeliver LMS sfruttato per distribuire BLUEBEAM e Cobalt Strike BEACON

Si parla di:
Toggle

Un attore di minacce non ancora attribuito ha sfruttato una vulnerabilità zero-day nel sistema LMS KnowledgeDeliver, sviluppato dalla giapponese Digital Knowledge, per ottenere Remote Code Execution non autenticato e distribuire la web shell in-memory BLUEBEAM. L’indagine di Mandiant rivela un attacco sofisticato a più strati: dalla deserialization di ViewState ASP.NET al social engineering degli utenti finali con un falso plugin di autenticazione che installa Cobalt Strike BEACON, personalizzato per organizzazione. Una vulnerabilità che colpisce sistemi universitari e aziendali in tutto il mondo a causa di una scelta progettuale fatale: chiavi crittografiche condivise tra tutte le installazioni.

La radice del problema: chiavi macchina hardcoded

KnowledgeDeliver è un Learning Management System (LMS) enterprise ampiamente utilizzato in Giappone e in numerosi contesti educativi e corporate internazionali. Come molte applicazioni ASP.NET, utilizza la funzionalità ViewState per preservare lo stato delle pagine web tra una richiesta e l’altra. ViewState è protetto tramite una machineKey: una coppia di chiavi crittografiche (validationKey + decryptionKey) che garantiscono l’autenticità e la riservatezza dei dati serializzati inviati tra client e server.

Il difetto critico di KnowledgeDeliver, ora tracciato come CVE-2026-5426, consiste nell’utilizzo di valori machineKey statici e identici in tutte le installazioni del prodotto. Digital Knowledge distribuiva il software con chiavi hardcoded nel file web.config, anziché generare valori unici per deployment. Il risultato è devastante: chiunque abbia accesso a una singola installazione — anche la propria — può ricavare le chiavi e usarle per forgiare payload ViewState malevoli validi su qualunque altro server che esegue KnowledgeDeliver nel mondo.

La catena di attacco: da ViewState a RCE

L’exploitation della vulnerabilità segue un pattern ben documentato, già osservato in attacchi a Sitecore e in campagne evidenziate da Microsoft riguardanti chiavi macchina esposte. L’attaccante costruisce un payload serializzato contenente istruzioni arbitrarie e lo inserisce nel parametro __VIEWSTATE di una normale richiesta HTTP. Il server ASP.NET, fidandosi della firma crittografica (valida perché l’attaccante conosce la chiave), deserializza il payload e lo esegue con i privilegi del processo IIS (tipicamente Network Service o Application Pool Identity).

L’intera operazione non richiede credenziali, autenticazione pregressa o interazione utente sul lato server. Un singolo POST HTTP con il ViewState artefatto è sufficiente a ottenere esecuzione di codice remoto. Mandiant ha datato la compromissione iniziale alla fine del 2025, suggerendo che l’attore fosse a conoscenza della vulnerabilità mesi prima della disclosure pubblica avvenuta il 24 febbraio 2026.

BLUEBEAM: la web shell fantasma

Una volta ottenuto il foothold iniziale, l’attaccante ha distribuito BLUEBEAM, una web shell .NET nota anche come Godzilla. Ciò che distingue BLUEBEAM dalle web shell tradizionali è la sua natura interamente in-memory: il malware non scrive file su disco ma viene caricato direttamente nel processo worker IIS (w3wp.exe), riducendo drasticamente la superficie di rilevamento per strumenti forensi e antivirus basati sulla scansione del filesystem.

BLUEBEAM comunica con il suo operatore tramite richieste HTTP POST cifrate, mascherandosi come normale traffico web. Attraverso questo canale, l’attaccante può eseguire comandi arbitrari, caricare ulteriori payload, modificare file e mantenere persistenza nell’ambiente compromes. Mandiant ha osservato l’uso del tool di sistema icacls per allargare i permessi sul filesystem, indebolendo ulteriormente i controlli di sicurezza dell’host compromesso.

Il vettore secondario: social engineering sugli utenti finali

L’attacco non si è fermato al server. Con l’accesso a w3wp.exe, l’attaccante ha manomesso i file JavaScript legittimi del portale LMS, iniettando codice malevolo nelle pagine visitate dagli studenti e dai dipendenti. Il codice iniettato mostrava un avviso di sicurezza convincente, informando l’utente della necessità di installare un “plugin di autenticazione” aggiuntivo per continuare ad accedere alla piattaforma. Parallelamente, caricava script da infrastruttura controllata dall’attaccante.

Gli utenti che installano il falso plugin vengono infettati con un Cobalt Strike BEACON, il framework di post-exploitation commerciale più abusato nel panorama delle minacce avanzate. L’elemento che rivela la natura mirata e pianificata dell’operazione è la personalizzazione del payload: il BEACON era cifrato con una chiave derivata dal nome dell’organizzazione vittima, dimostrando che l’attaccante aveva condotto ricognizione preventiva e aveva predisposto un payload ad hoc per ogni target.

Timeline degli eventi

• Fine 2025: Compromissione iniziale rilevata da Mandiant durante un incident response
• 24 febbraio 2026: Data limite per le installazioni vulnerabili (le versioni precedenti a questa data con machineKey di default sono esposte)
• 25 maggio 2026: Pubblicazione dell’advisory Mandiant/Google Cloud e assegnazione CVE-2026-5426

Indicatori di compromissione (IoC)

# BLUEBEAM web shell
SHA-256: 7c1f99dca8e5a7897892f9d224a6495023a2cfd2671697d229d355978c415ed2
File:    LoadLibrary.dll (caricato in-memory da w3wp.exe)
# CVE
CVE-2026-5426 – KnowledgeDeliver ASP.NET machineKey RCE (CVSS: critico)
# Segnali di detection
Windows Application Log - Event ID 1316 (ViewState validation failure/anomalia)
Processo: w3wp.exe che genera child process cmd.exe, powershell.exe, cscript.exe
File JS del portale modificati con tag 
User-Agent anomali nelle richieste POST a pagine .aspx (concatenazione di UA multipli)
Uso di icacls.exe da processi IIS per modifica permessi
# Pattern ViewState malevolo
Parametro __VIEWSTATE con lunghezza anomala (>50KB)
Richieste POST a pagine .aspx che non prevedono ViewState volumioso

Remediation e due righe per i difensori

La mitigazione primaria e indispensabile è la rotazione immediata dei valori machineKey a valori unici e crittograficamente robusti per ogni singola installazione. Le chiavi devono essere generate con un generatore di numeri casuali sicuro (CSPRNG) e non devono mai essere condivise tra ambienti diversi. La configurazione va inserita nel file web.config sotto il tag <system.web><machineKey validationKey="..." decryptionKey="..." />. Oltre alla remediation tecnica, le organizzazioni dovrebbero limitare l'accesso al portale LMS a range IP fidati, condurre threat hunting retrospettivo alla ricerca di sign of compromise elencati sopra, verificare l'integrità dei file JavaScript del portale tramite confronto hash, e investigare eventuali installazioni del presunto "plugin di autenticazione" sulle macchine degli utenti finali. Questo incidente è un promemoria sistematico del rischio insito nelle configurazioni di default condivise: una singola chiave hardcoded può trasformare un'applicazione enterprise globale in una superficie di attacco che compromette simultaneamente organizzazioni altrimenti non correlate.

Destinazione Stelle

2026-05-25 07:26:42

Quiz del lunedì. A che temperatura operava lo strumento HFI del satellite europeo Planck?

Appuntamento a domani per la discussione delle risposte, non suggerite e non cercate su internet!

#QuizTime
@astronomia

Destinazione Stelle

2026-05-26 07:08:25

Planck è stato un satellite europeo, operativo tra il 2009 e il 2013, con l’obiettivo di misurare la radiazione cosmica di fondo e migliorare la nostra conoscenza sulle origini e l’evoluzione dell’universo. Era equipaggiato con due sofisticati strumenti: il Low Frequency Instrument (LFI) e l'High Frequency Instrument (HFI). Oltre a partecipare alla costruzione del satellite, l'Italia è stata responsabile dell’LFI, con il ruolo di Principal Investigator affidato a Nazzareno Mandolesi dell’INAF-IASF di Bologna, ma ha partecipato anche alla realizzazione dell'HFI. Per entrambi gli strumenti, gli scienziati italiani sono stati fortemente coinvolti nell’attività scientifica legata alla missione, che ha realizzato la più accurata e dettagliata mappatura dell'intera volta celeste alle frequenze delle microonde mai ottenuta fino a quel momento.

Per misurare le infinitesimali variazioni di temperatura della radiazione cosmica di fondo, pari a pochi milionesimi di grado, i due strumenti dovevano essere mantenuti a temperature eccezionalmente basse. Questo obiettivo è stato raggiunto con una complessa catena di raffreddamento a stadi successivi. I due strumenti lavoravano a temperature diverse ed erano inseriti uno dentro l'altro.

Per prima cosa era necessario isolare gli strumenti dalla parte “calda” del satellite, il modulo di servizio orientato verso il sole. Questo obiettivo è stato ottenuto con un sistema di scudi termici molto ingegnoso ed eccezionalmente efficiente chiamato “V-grooves”: lo stesso principio poi adottato dal telescopio James Webb. In questo modo si è riusciti a portare la temperatura del payload a 50 Kelvin, circa -223 °C, una temperatura già molto bassa ma non ancora sufficiente.

Lo strumento LFI veniva poi portato a circa 20 Kelvin (-253 °C) con un particolare refrigeratore a idrogeno che aveva la caratteristica di non usare alcuna parte meccanica in movimento, eliminando così qualsiasi vibrazione che potesse disturbare le misurazioni scientifiche.

Lo strumento HFI veniva invece raffreddato con tre stadi successivi, l’ultimo dei quali sfruttava il principio della “diluzione d’elio”: questo stadio faceva miscelare continuamente due isotopi rari dell'elio, l'elio-3 e l'elio-4, con un processo endotermico, capace di assorbire calore, un po’ come l'evaporazione di un liquido, e di sottrarre le ultime frazioni di microwatt, per arrivare a una temperatura di un decimo di Kelvin (-273,05 °C). La temperatura "naturale" della radiazione cosmica di fondo è di circa 2,7 K (-270,45 °C), quindi lo strumento HFI era molto più freddo dell’ambiente circostante: un risultato possibile soltanto grazie a sistemi di raffreddamento attivi.

All’epoca lo strumento HFI era l’oggetto più freddo noto nello spazio, nonché il più freddo oggetto artificiale, ma in seguito questo record è stato superato. Attualmente l’esperimento della NASA Cold Atom Lab (CAL), a bordo della Stazione Spaziale Internazionale, è in grado di arrivare a temperature dell'ordine di poche decine di picokelvin, cioè meno di un decimiliardesimo di Kelvin.

@astronomia

♲ @destinazione_stelle@poliversity.it:

Quiz del lunedì. A che temperatura operava lo strumento HFI del satellite europeo Planck?
Appuntamento a domani per la discussione delle risposte, non suggerite e non cercate su internet!

#QuizTime
@astronomia