BlackX aggira Secure Boot anche su Windows aggiornati: pista APT41

🛡️ Executive Summary

• Kaspersky scopre BlackX, un nuovo bootkit UEFI utilizzato contro organizzazioni diplomatiche di Tagikistan, Uzbekistan e Turkmenistan, con attribuzione ad APT41 a confidenza media.
• Il malware sfrutta Baton Drop, CVE-2022-21894, anche su Windows aggiornati perché la revoca del certificato Windows Production PCA 2011 non viene necessariamente applicata insieme alle patch.
• BlackX installa un driver kernel che interferisce con le difese e distribuisce backdoor capaci di utilizzare Google Drive, OneDrive, Yandex.Disk e infrastrutture C2 dedicate.

BlackX è un nuovo bootkit UEFI capace di compromettere computer Windows anche quando gli aggiornamenti di sicurezza risultano installati, sfruttando una debolezza nella procedura di revoca dei certificati utilizzati da Secure Boot. La scoperta arriva dai ricercatori di Kaspersky GReAT, che hanno identificato il malware all’inizio del 2026 durante un’operazione di cyber spionaggio contro organizzazioni diplomatiche in Tagikistan, Uzbekistan e Turkmenistan. Il codice recupera tecniche già utilizzate da BlackLotus e introduce nuove componenti per interferire con le soluzioni di sicurezza, mantenere l’accesso ai sistemi compromessi ed eseguire ulteriori payload. L’indagine attribuisce la campagna ad APT41 con confidenza media, ma il dato tecnicamente più rilevante riguarda Microsoft: installare gli aggiornamenti Windows non garantisce che tutte le revoche necessarie a proteggere Secure Boot siano state effettivamente applicate.

BlackX recupera BlackLotus e colpisce le organizzazioni diplomatiche dell’Asia centrale

La ricerca pubblicata da Kaspersky GReAT il 22 ottobre 2026 documenta il ritorno operativo di una tecnica che aveva attirato l’attenzione della comunità di sicurezza già nel 2022, quando BlackLotus era stato pubblicizzato nei forum criminali come un bootkit capace di aggirare Secure Boot per circa 5.000 dollari. Nel marzo 2023 ESET aveva dimostrato che quelle capacità erano reali, identificando un malware capace di utilizzare CVE-2022-21894, conosciuta come Baton Drop, per eludere i controlli previsti durante l’avvio del sistema operativo. Il precedente aveva evidenziato la possibilità di aggirare Secure Boot attraverso componenti UEFI vulnerabili, ma dopo gli interventi di Microsoft non erano state documentate pubblicamente nuove campagne basate su BlackLotus. La situazione cambia con BlackX, identificato in attacchi mirati contro rappresentanze e organizzazioni diplomatiche dell’Asia centrale.

Gli aggressori non utilizzano il bootkit come vettore iniziale di compromissione: BlackX viene installato dopo che la rete bersaglio è stata violata e sono stati ottenuti privilegi amministrativi. Kaspersky ha osservato un installer denominato inst.exe e un file senza estensione, PVMDIJGKAX2, contenente i componenti necessari all’infezione e cifrato attraverso RC4. L’eseguibile non incorpora direttamente stringhe malevole o payload riconoscibili, perché il materiale operativo viene recuperato dal secondo file attraverso una chiave fornita al momento dell’esecuzione. Questa separazione rende più complicata l’analisi statica del programma di installazione e permette agli operatori di trasferire le componenti dell’attacco senza concentrarle in un unico eseguibile. Il pacchetto modifica file presenti nella partizione di sistema e nella partizione EFI, preparando l’esecuzione del codice malevolo durante l’avvio. L’obiettivo consiste nell’ottenere il controllo di una fase precedente al caricamento completo di Windows, quando le normali protezioni del sistema operativo non sono ancora pienamente operative. La somiglianza con BlackLotus è significativa, ma non dimostra che gli autori siano gli stessi: Kaspersky ipotizza che gli sviluppatori di BlackX abbiano ricostruito la tecnica attraverso reverse engineering oppure acquisito privatamente il codice sorgente del vecchio bootkit, che non risulta pubblicamente disponibile.

Leggi anche: Microsoft impiegherà quasi un anno per correggere un bug di Secure Boot

Baton Drop permette di aggirare Secure Boot perché la revoca dei certificati non è automatica

L’elemento più importante dell’indagine riguarda il motivo per cui BlackX è riuscito a operare su macchine che avevano già ricevuto gli aggiornamenti Microsoft. Durante le prime analisi, i ricercatori avevano ipotizzato che gli aggressori avessero sfruttato sistemi non aggiornati, considerando che Baton Drop era stata resa pubblica nel 2022 e che Microsoft aveva successivamente distribuito mitigazioni contro gli attacchi alla catena di avvio. La verifica delle macchine compromesse ha invece dimostrato che il problema non risiedeva necessariamente nell’assenza delle patch, ma nell’attivazione incompleta delle contromisure. Il meccanismo di protezione richiede infatti la revoca del certificato Windows Production PCA 2011, utilizzato per firmare componenti di avvio Windows che possono essere abusati da attaccanti in possesso delle tecniche necessarie a sfruttare le vecchie vulnerabilità. Questa revoca viene registrata nel database DBX di UEFI Secure Boot, che contiene certificati e firme esplicitamente non attendibili. Se la revoca non viene applicata, il firmware può continuare ad accettare componenti precedentemente firmati, anche se appartengono a una catena di avvio ormai considerata insicura.

La documentazione Microsoft sulla gestione delle revoche Secure Boot descrive una procedura articolata che prevede l’introduzione delle nuove autorità di certificazione del 2023, l’aggiornamento del boot manager, la revoca della vecchia catena di fiducia e l’applicazione delle protezioni contro il rollback. Le misure sono collegate al percorso di mitigazione di CVE-2023-24932, successivamente utilizzato anche per contrastare tecniche riconducibili a BlackLotus. La distribuzione graduale risponde a un problema concreto: revocare indiscriminatamente vecchi certificati potrebbe impedire l’avvio di dispositivi, supporti di ripristino e configurazioni dual-boot ancora dipendenti dai componenti precedenti. Il risultato è una protezione che può richiedere interventi ulteriori rispetto alla normale installazione degli aggiornamenti, con la conseguenza che un sistema apparentemente aggiornato mantiene una configurazione Secure Boot vulnerabile.

Kaspersky evidenzia inoltre che il certificato Windows Production PCA 2011 è scaduto il 19 ottobre 2026, ma la scadenza non equivale alla sua presenza nella lista di revoca: un firmware che continua a considerarlo attendibile può ancora caricare binari vulnerabili firmati attraverso quella catena. È una distinzione fondamentale anche alla luce delle precedenti ricerche sugli shim UEFI firmati da Microsoft e utilizzabili per aggirare Secure Boot. Nel caso BlackX, la catena Baton Drop viene sfruttata per installare Machine Owner Keys personalizzate, ottenendo la possibilità di caricare componenti EFI arbitrari e manipolare il processo di avvio senza che le normali verifiche blocchino l’operazione.

Il driver kernel di BlackX tenta di neutralizzare antivirus ed eventi di sicurezza

Una volta ottenuta la possibilità di eseguire codice nella catena di avvio, BlackX introduce un driver malevolo nel kernel Windows. Il componente è diverso da quello utilizzato da BlackLotus e risulta firmato con un certificato attribuito a Wenjiang District Mingyu Network Technology Service Studio, organizzazione identificata nella ricerca attraverso la denominazione cinese 温江区明宇网络技术服务工作室. Il certificato, con numero seriale 0bcdf5e0da32d68900b8b7638459d072, risultava revocato al momento della pubblicazione dell’analisi. La firma digitale rappresenta comunque un elemento importante per comprendere la strategia offensiva: gli attaccanti combinano l’abuso della catena Secure Boot con un driver capace di operare a livello kernel, dove possono intervenire sulle funzioni utilizzate dagli strumenti di sicurezza per osservare il comportamento del sistema.

Il driver tenta di disabilitare callback associate a processi, thread e Registro di Windows, riducendo la visibilità delle attività che le soluzioni di protezione normalmente utilizzano per identificare comportamenti sospetti. Interferisce inoltre con i provider Event Tracing for Windows (ETW), ostacolando la raccolta della telemetria necessaria a riconoscere l’esecuzione di codice e le modifiche al sistema. Alcune procedure sono progettate per intervenire soltanto quando vengono rilevati prodotti Kaspersky o Avast, ma i test dinamici condotti dai ricercatori hanno dimostrato che le routine esaminate non riuscivano a interferire efficacemente con i prodotti Kaspersky. La presenza di codice destinato a disabilitare un antivirus non dimostra quindi che tale protezione sia stata effettivamente neutralizzata.

BlackX introduce anche un meccanismo per impedire l’accesso diretto ai propri file: quando vengono intercettate determinate richieste del kernel rivolte ai componenti malevoli, il driver restituisce un handle associato a calc.exe anziché al file richiesto. Questa tecnica può alterare i risultati delle operazioni di ispezione e complicare la raccolta degli artefatti durante la risposta a un incidente. Il comportamento conferma che la persistenza attraverso UEFI è soltanto una parte dell’operazione, perché il malware dispone anche di strumenti destinati a contrastare l’analisi una volta che Windows è stato avviato.

Le backdoor utilizzano Google Drive, OneDrive e un payload Rust per lo spionaggio

La componente UEFI non costituisce il fine ultimo della campagna, ma il meccanismo attraverso il quale gli aggressori distribuiscono e proteggono ulteriori strumenti di cyber spionaggio. Kaspersky ha identificato due differenti payload user-mode associati a BlackX. Il primo è un Remote Access Trojan capace di caricare ed eseguire ulteriori componenti .NET, utilizzando servizi di archiviazione cloud come Google Drive, Microsoft OneDrive e Yandex.Disk per comunicare con l’infrastruttura di comando e controllo. Il RAT interpreta i file presenti nello spazio cloud in base a suffissi specifici: 0X01 identifica componenti .NET da eseguire, 0X02 contiene i risultati dei comandi, 0X03 e 0X04 vengono impiegati per il caricamento dei file, 0X05 e 0X06 gestiscono il download verso la macchina compromessa, mentre SSSR contiene informazioni iniziali sul sistema.

L’utilizzo di servizi cloud legittimi permette di inserire le comunicazioni malevole all’interno di traffico che potrebbe essere normalmente autorizzato dalle politiche di rete aziendali. Non significa che Google, Microsoft o Yandex siano coinvolte nell’operazione, ma che gli aggressori sfruttano infrastrutture commerciali disponibili pubblicamente per ridurre la riconoscibilità delle proprie comunicazioni. Una dinamica di questo tipo era già emersa nelle operazioni di spionaggio contro ministeri e amministrazioni dell’Asia centrale attraverso OctLurk e SilkLurk, anche se la nuova ricerca non dimostra che le campagne appartengano alla stessa operazione.

Il secondo payload è stato denominato OxiDLLRunner. Si tratta di una DLL malevola offuscata attraverso OLLVM e caricata mediante un eseguibile legittimo denominato googleupdate.exe, il cui nome originale è jcef_helper.exe. La DLL decifra il contenuto del file v8_context_snapshot.bin, ottenendo uno shellcode seguito da un eseguibile PE sviluppato in Rust. Quest’ultimo comunica con il server di comando e controllo www[.]archivetj[.]com e può ricevere ulteriori librerie DLL che esportano la funzione create_plugin, eseguendole in thread separati. L’architettura introduce una capacità modulare: gli operatori possono caricare nuove funzionalità senza dover modificare necessariamente il bootkit installato sulla macchina. BlackX combina quindi il controllo della fase di avvio, l’interferenza con la telemetria kernel e l’esecuzione modulare di strumenti di spionaggio, separando la persistenza dalle capacità operative utilizzate contro i bersagli.

Continua con:

HybridPetya: ransomware UEFI con bypass Secure Boot

APT41 attacca infrastrutture IT in Africa

APT41 è il sospettato principale, ma la vera emergenza riguarda le revoche Windows

Kaspersky attribuisce la campagna BlackX ad APT41 con un livello di confidenza medio, basandosi su tre elementi tecnici che suggeriscono una continuità con precedenti operazioni riconducibili all’ecosistema degli attori cinesi. Il primo riguarda una ricerca ESET pubblicata nel giugno 2026 su FishMonger, gruppo che parte della comunità di threat intelligence collega ad APT41. In quella campagna era stato individuato un impianto kernel con un percorso di compilazione contenente l’identificatore xdd, insieme a indizi della possibile presenza di un bootkit UEFI non identificato. Kaspersky ha rilevato lo stesso identificatore in diverse componenti BlackX e considera plausibile che il malware analizzato sia proprio il bootkit richiamato nella precedente indagine. Gli altri elementi riguardano il ricorso al DLL sideloading, l’utilizzo di file cifrati e l’offuscamento attraverso OLLVM, tecniche frequentemente osservate nelle campagne condotte da gruppi sinofoni. Nessuno di questi indicatori costituisce però una prova definitiva dell’identità degli operatori: l’attribuzione rimane una valutazione di intelligence sostenuta da somiglianze tecniche e collegamenti investigativi, non l’accertamento diretto dell’identità degli autori. Il quadro si inserisce nelle precedenti operazioni FishMonger ricostruite attraverso l’operazione FishMedley, ma non autorizza a considerare automaticamente coincidenti gruppi, campagne e infrastrutture.

Per gli amministratori Windows la conseguenza più importante della scoperta riguarda invece la verifica effettiva dello stato delle revoche Secure Boot. La presenza degli ultimi aggiornamenti cumulativi non è sufficiente per certificare che la macchina abbia adottato il nuovo boot manager, installato le autorità di certificazione aggiornate e applicato la revoca della vecchia catena Windows Production PCA 2011. Microsoft documenta la possibilità di controllare l’applicazione dell’aggiornamento DBX attraverso l’evento 1037 nel registro eventi Windows, mentre la transizione deve essere coordinata con la verifica della compatibilità del firmware, dei supporti di ripristino e degli eventuali sistemi dual-boot. L’attivazione indiscriminata delle revoche senza queste verifiche può compromettere l’avvio di configurazioni ancora dipendenti da componenti precedenti.

La risposta difensiva deve inoltre includere il controllo degli accessi amministrativi e degli eventi di compromissione già avvenuti, perché BlackX richiede privilegi elevati ottenuti prima dell’installazione del bootkit. Nelle organizzazioni che gestiscono workstation diplomatiche, sistemi istituzionali o infrastrutture aziendali sensibili, la verifica deve quindi interessare sia la catena UEFI sia le attività che hanno consentito agli aggressori di raggiungerla. La ricerca non documenta vittime italiane né una distribuzione indiscriminata del malware, ma identifica una classe di rischio applicabile anche ai sistemi Windows utilizzati in Italia quando le mitigazioni Secure Boot risultano incomplete.

La scoperta di BlackX evidenzia soprattutto un limite della tradizionale gestione delle patch: un aggiornamento installato non coincide necessariamente con una protezione attivata. Microsoft ha costruito un percorso graduale per impedire che la revoca dei vecchi certificati renda inutilizzabili dispositivi e supporti di avvio, ma la complessità di questa transizione ha lasciato una finestra operativa sfruttabile dagli aggressori. BlackX dimostra che una vulnerabilità conosciuta da anni può conservare valore offensivo quando la correzione dipende da procedure ulteriori che gli amministratori non hanno completato. Il problema non è soltanto il ritorno di BlackLotus sotto una nuova forma, ma la possibilità che sistemi considerati aggiornati continuino a fidarsi proprio dei componenti che le mitigazioni avrebbero dovuto escludere.