APT41 adotta tecniche da BlackLotus: il bootkit BlackX ha colpito diplomatici in Asia centrale

Secondo l'analisi di Kaspersky GReAT, singola fonte disponibile, nel primo trimestre 2026 il gruppo APT41 ha utilizzato il bootkit UEFI BlackX contro organizzazioni diplomatiche in Tajikistan, Uzbekistan e Turkmenistan. L'attribuzione ad APT41 si basa su pattern operativi proprietari di Kaspersky, con livello di confidenza "medium". BlackX sfrutta una vulnerabilità non assegnata a CVE standard, denominata Baton Drop nel report, per compromettere Secure Boot. Il bootkit installa un driver kernel firmato con certificato revocato e mantiene persistenza attraverso un RAT user-mode che comunica via cloud storage pubblico.

Come BlackX aggira Secure Boot attraverso Baton Drop

Il meccanismo d'ingresso di BlackX nel firmware UEFI passa attraverso la vulnerabilità Baton Drop. Il bootkit installa Machine Owner Keys (MOK) custom nel database del firmware: questo consente di caricare immagini EFI arbitrarie senza che il controllo di integrità di Secure Boot le blocchi. L'implementazione è "remarkably similar" a quella osservata in BlackLotus, con differenze che indicano un lavoro di reverse-engineering o acquisizione piuttosto che una copia identica.

Il codice sorgente di BlackLotus non è mai stato pubblicato online. Secondo Kaspersky GReAT, "the source code of the BlackLotus bootkit has never been published online". La similarità tecnica elevata tra i due bootkit implica che gli operatori di APT41 abbiano avuto accesso al codice originale attraverso acquisto o decompilazione, non attraverso diffusione pubblica.

Il driver firmato e le procedure anti-sicurezza inefficaci

BlackX carica un driver kernel malevolo firmato con un certificato legittimo appartenente alla Wenjiang District Mingyu Network Technology Service Studio. Il numero di serie del certificato è 0bcdf5e0da32d68900b8b7638459d072; la fonte conferma che il certificato era già revocato al momento della pubblicazione dell'analisi. Il metodo di acquisizione del certificato non è specificato dalla fonte.

Il driver implementa tecniche anti-analisi che mirano a neutralizzare le soluzioni di sicurezza presenti sul sistema. Disabilita callback di processo, thread e registry intercettando le registrazioni dei componenti di sicurezza. Manipola inoltre i provider ETW (Event Tracing for Windows) per ridurre la visibilità delle azioni malevole. Alcune procedure includono codice specifico per Kaspersky e Avast, ma l'analisi dinamica diretta ha dimostrato che "these procedures are useless—they fail to interfere with Kaspersky products in any way". Il driver protegge i file del bootkit intercettando le richieste del kernel e restituendo handle a calc.exe, rendendo invisibili i componenti alla lettura diretta del filesystem.

La persistenza e il canale C2 su cloud storage

Dopo la fase di boot, BlackX deploya un RAT user-mode che carica payload .NET. Il meccanismo di comunicazione con il server di comando e controllo sfrutta servizi di cloud storage pubblico: la fonte ha osservato l'uso di Google Drive, OneDrive e Yandex.Disk. Il RAT interpreta i file presenti sullo storage in base a un suffisso numerico nel nome: 0X01 indica l'esecuzione del metodo TEST.Class1.RunCMD, 0X02 raccoglie i risultati.

La fonte non specifica se l'uso di tre servizi cloud distinti introduca ridondanza tattica o complichi il blocco perimetrale. Non descrive inoltre se il traffico verso queste piattaforme si mescoli con quello ordinario delle reti bersaglio.

"we rarely see APT actors borrow ideas or code from cybercrime actors" — Kaspersky GReAT (Securelist)

Perché è importante

L'adozione da parte di APT41 di tecniche sviluppate per il crimeware BlackLotus incrina la separazione tradizionale tra attori statalisti e operatori criminali. Secondo la citazione diretta della fonte riportata sopra, questa dinamica è rara: i gruppi APT tendono a sviluppare strumenti proprietari o a ereditare infrastrutture da altre operazioni statali, non a recuperare codice dal mercato criminale.

Il bootkit UEFI rappresenta una classe di minaccia con visibilità estremamente ridotta. Gli strumenti di sicurezza tradizionali operano a livello di sistema operativo; un compromesso nel firmware precede qualsiasi controllo runtime. La persistenza si estende oltre la riformattazione del disco e la reinstallazione del sistema operativo. La compromissione di Secure Boot, elemento architetturale della fiducia nella catena di avvio di Windows, erode un presupposto che molte organizzazioni considerano ancora solido.

Cosa sappiamo e cosa non sappiamo

Cosa fare adesso

Misure standard di mitigazione UEFI (non specifiche alla minaccia documentata):

• Verificare l'integrità del database MOK (Machine Owner Keys) sui sistemi con asset diplomatici o governativi nelle aree geografiche indicate
• Confermare che i controlli di revoca certificati siano attivi e applicati correttamente
• Monitorare il traffico verso servizi di cloud storage pubblico come indicatore anomalo su sistemi con profilo di rischio elevato
• Valutare la scansione del firmware UEFI come parte di procedure di incident response su sistemi sospetti

Queste raccomandazioni rappresentano misure standard di sicurezza UEFI; la fonte non fornisce indicazioni operative specifiche alla minaccia BlackX.

Chiusura editoriale

Il caso BlackX illustra una convergenza tra strumenti criminali e operazioni statali che Kaspersky GReAT descrive come rara. La similarità tecnica con BlackLotus, il cui codice sorgente non è mai stato pubblico, solleva questioni sulle modalità di accesso al bootkit originale. Al tempo stesso, l'attribuzione ad APT41 con "medium confidence" e la mancanza di fonti indipendenti impongono cautela nella valutazione del quadro complessivo. Il report di Kaspersky rimane, al momento, l'unica fonte disponibile su questa campagna.

Fonti

• securelist.com