UEFI Bootkit: dal laboratorio alla realtà, con un focus su Bootkitty e BlackLotus

I Bootkit UEFI In pochi anni, sono passati dall'essere un concetto di laboratorio a diventare un vero grattacapo per difensori e produttori. In questo ambito, il confine tra proof of concept e minaccia operativa è labile e casi come Loto Nero o la recente scoperta di Bootkitty su Linux Lo dimostrano ampiamente.

Questo articolo raccoglie e spiega, con linguaggio chiaro e dettagli tecnici quando aggiungono valore, i più rilevanti pubblicati da ricercatori e aziende del settore: dal primo PoC del 2012 alle campagne moderne, comprese vulnerabilità come CVE-2024-7344 che consentono di aggirare Secure Boot, tecniche di evasione, IoC e misure di rilevamento e mitigazione che funzionano davvero nel mondo reale.

Cos'è un bootkit UEFI e perché è così problematico?

Un bootkit UEFI è un impianto che funziona prima del sistema operativo, con la capacità di controllare il flusso di Boot, disabilitare i controlli e caricare componenti con privilegi elevati. Operando a un livello così basso, è possibile eludere antivirus tradizionale e anche certi "misure di avvio sicuro" se sfrutta difetti o configurazioni permissive.

Nel mondo reale, sono già stati osservati impianti e tecniche UEFI persistenti, come LoJax, MosaicRegressor o Rimbalzo lunare, traguardi che mostrano come un attore può occupare il firmware e padroneggiare le fasi critiche dello stivale, complicando il analisi forense e bonifica.

per difendere Windows, Microsoft concatena diversi livelli: Secure Boot (UEFI convalida il caricatore con certificati attendibili), Avvio affidabile (il kernel convalida il resto dei componenti), ELAM (Early Launch Antimalware, che ispeziona i driver di avvio) e Stivale misurato (Misurazioni TPM e attestazione remota). Si tratta di barriere utili, ma non infallibili, per vulnerabilità dell'ecosistema stesso UEFI o impostazioni di attendibilità eccessivamente ampie. Inoltre, è possibile scudo Windows con Credential Guard, BitLocker e WDAC per ridurre il rischio di persistenza a lungo termine.

Dalle PoC alla vita reale: cronologia e attori chiave

Il viaggio inizia nel 2012 con il PoC di Andrea Allievi per Windows su UEFI, seguito da progetti come EfiGuard, Boot Backdoor o UEFI-bootkit. Ci sono voluti anni prima che casi concreti fossero documentati come ESPetro (ESET, 2021) o il Kit di avvio FinSpy (Kaspersky, 2021), e nel 2023 ha fatto irruzione sulla scena Loto Nero, il primo bootkit UEFI in grado di Bypassare l'avvio sicuro sui sistemi completamente aggiornatiNegli ambienti di laboratorio è comune testare il malware su una macchina virtuale per valutare PoC e rilevamenti senza mettere a rischio l'infrastruttura produttiva.

Qualcosa era rimasto costante fino ad ora: l'obiettivo era esclusivamente computer WindowsQuesta supposizione è stata infranta quando un'app UEFI chiamata VirusTotal è apparsa su VirusTotal nel novembre 2024. bootkit.efiL'analisi ha rivelato un bootkit, soprannominato dai suoi autori come Bootkitty, progettato per Linux (gratuito)Secondo la telemetria, non esiste un effettivo dispiegamento confermato; e gli autori stessi, collegati al programma di addestramento coreano Il meglio del meglio (BoB), hanno chiarito che si trattava di un verifica teorica con l'obiettivo di sensibilizzare.

Il binario Bootkitty è firmato con un certificato autofirmatoCiò significa che non verrà eseguito con Secure Boot abilitato a meno che installare i certificati dell'attaccanteTuttavia, la sua logica illustra come un attore può correggere, in memoria, i componenti del caricatore (GRUB) e kernel linux per aggirare i controlli.

Bootkitty nel dettaglio: artefatti, compatibilità e cosa modifica

Il bootkit contiene funzioni inutilizzate che stampano l'arte ASCII con il nome Bootkitty e un elenco di possibili autori. Mostra anche stringhe di testo ad ogni avvio e riferimenti a Gatto nero all'interno del suo output e in un modulo kernel correlato, non correlato al ransomware ALPHV/BlackCat; in parte perché Bootkitty è scritto in C, mentre ALPHV si sviluppa in Rust.

La sua compatibilità è limitata. Per individuare le funzioni da toccare, utilizzare modelli di byte codificati (una tecnica classica del bootkit), ma i modelli scelti non coprono bene più versioni del kernel o di GRUB. Il risultato è che l'impianto è funzionale solo in un set molto limitato di configurazioni e, inoltre, patch offset fissi dopo la decompressione del kernel: se gli offset non corrispondono alla versione, potrebbe sovrascrivere dati casuali e causare riattaccare invece di impegnarsi.

Lo stivale inizia con shim eseguendo Bootkitty, che prima interroga lo stato di Avvio sicuro e inserisce degli hook in due protocolli di autenticazione UEFI: EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication y EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationStateIn entrambi i casi, imposta l'output su return EFI_SUCCESSO, annullando di fatto il controllo di integrità dell'immagine PE durante il pre-OS.

Bootkitty carica quindi un GRUB legittimo da un percorso hardcoded sull'ESP (/EFI/ubuntu/grubx64-real.efi), lo corregge in memoria e funzioni chiave dei ganci prima che venga eseguito.

Collegamento a GRUB e decompressione del kernel Linux

L'impianto altera la funzione immagine_iniziale del modulo immagine di GRUB, responsabile dell'avvio dei binari PE già caricati (come Stub del kernel EFI, vmlinuz.efi/vmlinuz). Sfrutta il fatto che il kernel è già in memoria e inserisci un hook nella routine che decomprime l'immagine del kernel effettiva (probabilmente zstd_decompress_dctx a seconda della build), quindi una volta decompresso, puoi applica una patch a caldo.

Modifica anche la funzione grub_verifiers_open, che decide se verificare l'integrità di ogni file caricato (moduli, kernel, configurazione, ecc.). L'hook ritorna immediatamente e quindi, evita qualsiasi verifica della firmaDa parte sua, l'adeguamento in shim_lock_verifier_init È confusionario: impone un flag di verifica più severo (GRUB_VERIFY_FLAGS_SINGLE_CHUNK), ma questa funzione non viene nemmeno chiamata dall'altro hook, lasciando Irrilevante.

Una volta decompresso il kernel, il codice Bootkitty applica tre modifiche alla memoria: riscrive il stringa versione/banner dal kernel con il testo "BoB13"; forzalo modulo_sig_check() restituisci 0 per il caricamento del kernel moduli non firmati; e sostituisce la prima variabile d'ambiente del processo init iniettare LD_PRELOAD=/opt/injector.so /init all'inizio dello spazio utente.

Iniezione tramite LD_PRELOAD Questa è una tattica classica per dare priorità a un oggetto condiviso ELF e sovrascrivere le funzioni. Qui la catena ha una particolarità (include "/init" accanto a LD_PRELOAD), un dettaglio che rafforza il carattere di PoC incompiuto piuttosto che un'operazione raffinata. I binari presumibilmente iniettati non sono stati osservati, sebbene una successiva scrittura di terze parti abbia indicato che vengono utilizzati solo per caricare una fase aggiuntiva.

Indicatori, sintomi e un rimedio semplice

Se Bootkitty è presente, è possibile vedere suggerimenti visibili. Il comando uname -v visualizzerà la versione del kernel con il testo modificato e in dmesg Il banner potrebbe anche apparire modificato. Inoltre, è possibile rilevare che il processo PID1 (init) è stato rilasciato con LD_PRELOAD ispezionando /proc/1/ambiente, un segnale anomalo nei sistemi legittimi.

Nei test di laboratorio, il kernel appare contaminato dopo l'avvio con Bootkitty, un altro controllo empirico sui computer con Secure Boot abilitato è provare a caricare un modulo non firmato: Se è consentito il caricamento a caldo, suggerisce che controllo_firma_modulo è stato corretto.

Se il bootkit è stato installato sostituendo il binario GRUB con un intermediario (comportamento osservato), un modo semplice per ripristinarlo è spostare il file GRUB legittimo da /EFI/ubuntu/grubx64-real.efi al suo percorso originale /EFI/ubuntu/grubx64.efi per shim eseguilo e la catena di avvio continua senza il impiantare.

BCDropper e BCObserver: elementi collegati o solo una coincidenza?

Un modulo kernel non firmato soprannominato Bootkitty è stato trovato insieme a Bootkitty BCDropper, che condivide indizi con il bootkit: stringhe Gatto nero/gatto nero nei metadati e nei percorsi di debug, e una funzione di nascondere i file i cui prefissi includono "iniettore" (in linea con la variabile LD_PRELOAD che punta a /opt/injector.so).

BCDropper lascia dentro /opt/osservatore un ELF incorporato (chiamato Osservatore BCO) e lo lancia attraverso / bin / bashQuesto componente abbastanza semplice attende gdm3 è attivo e quindi carica un modulo kernel da /opt/rootkit_loader.ko utilizzando finito_modulo, assicurandosi di farlo dopo che il sistema si è completamente avviato.

Sebbene vi siano indizi di una relazione, non è possibile garantire che entrambi gli elementi provengano dallo stesso autore o che siano progettati per funzionare insieme. A peggiorare le cose, la versione del kernel menzionata nei suoi metadati (6.8.0-48-generic) non è nemmeno elencato tra quelli supportati dal kit di avvio.

IoC associati

I seguenti artefatti sono stati associati ai risultati discussi. Il loro valore è principalmente riferimento e laboratorio:

BlackLotus e CVE-2022-21894: la pietra miliare che ha aperto le porte

BlackLotus è sul mercato dal 2022 con un prezzo di circa 5.000 USD (più extra per ogni aggiornamento) e include tecniche per evasione anti-VM/anti-debug, il geofencing per evitare alcuni paesi (Armenia, Bielorussia, Kazakistan, Moldavia, Romania, Russia e Ucraina) e, soprattutto, lo sfruttamento di CVE-2022-21894 (Lancio del testimone) per bypassare l'avvio protetto e ottenere una persistenza robusta su macchine Windows 10/11 completamente patchate.

Il flusso descritto dalla comunità della sicurezza prevede una prima fase con disattivazione delle protezioni del sistema operativo, lo sfruttamento della vulnerabilità legacy in Secure Boot e la registrazione di una chiave del proprietario della macchina controllato dall'attaccante. Dopo ulteriori riavvii, l'impianto distribuisce un driver del kernel e un tipo di componente in modalità utente downloader per gestire la comunicazione di comando e controllo e costi aggiuntivi.

Per una difesa proattiva, la comunità ha pubblicato regole operative. Ad esempio, SOC Prime offre rilevamenti Sigma che cercano creazione sospetta di file firmware in System32 da processi non di sistema o Disattivazione HVCI tramite registrazione. Questi tipi di segnali, mappati su MITRE ATT&CK (ad esempio, T0857, T1562, T1112), aiutano a caccia all'attività anomala che di solito accompagna i bootkit; ci sono anche guide pratiche per Rileva processi dannosi con Process Explorer in ambienti Windows.

CVE-2024-7344: Caricamento di binari UEFI non attendibili tramite "reloader.efi"

Nel 2024 è stata scoperta una vulnerabilità particolarmente sensibile, CVE-2024-7344, che interessa più suite di ripristino firmate dal certificato Microsoft Corporation UEFI CA 2011La radice del problema è l'uso di un caricatore PE personalizzato nell'applicazione UEFI ricaricatore.efi, invece di API sicure Carica immagine/Avvia immagineIl binario decifra ed esegue il contenuto di un file mantello.dat senza verificare le firme secondo la politica di Secure Boot.

Il vettore non è limitato ai computer con il software installato, poiché un aggressore con privilegi elevati potrebbe distribuire il binario vulnerabile nell'ESP (partizione EFI) di qualsiasi sistema che si fida della CA UEFI di terze parti di Microsoft e provoca l'esecuzione di un UEFI non firmato durante l'avvio. I prodotti interessati includevano suite di Howyar, Greenware, Radix, SANFONG, Wasay, CES e Signal Computer, come corretto e revocato il 14 gennaio 2025.

Per verificare la protezione en PowerShell con privilegi elevati e nel Linux (LVFS/dbxtool):

# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

Questo caso riapre il dibattito sulla catena di fiducia: Microsoft mantiene due certificati ampiamente presenti sui computer UEFI consumer e aziendali (Produzione Windows CA 2011 y UEFI CA 2011 per terze parti). Il piano in atto è quello di migrare ai certificati 2023, a seguito di incidenti come BlackLotus e la proliferazione di bootloader vulnerabili firmati anni fa. Sui computer Nucleo protetto, di solito la CA UEFI di terze parti viene fornita disabilitato per impostazione predefinita.

Protezioni pratiche e personalizzazione di Secure Boot

Oltre l'applicazione Revoca UEFI e mantenere aggiornati firmware/OS (Windows Update e LVFS), ci sono misure che riducono la superficie di attacco: controllo del accesso all'ESP con regole di sicurezza, personalizza Secure Boot limitare la fiducia a ciò che è necessario (seguendo linee guida come quella del NSA) e distribuire attestazione con TPM per convalidare da remoto lo stato di avvio rispetto ai valori di riferimento.

In Windows, la combinazione di Avvio sicuro + avvio attendibile + ELAM + avvio misurato Offre barriere a strati: convalida del caricatore, controller di avvio ispezionati prima degli altri e un record firmato dal TPM che consente al firewall di separare i computer "puliti" da quelli con deviazioni. Negli ambienti gestiti, questo riduce il tempo de rilevamento e contenimento.

Su Linux, oltre alle revoche e al controllo ESP, vale la pena prestare attenzione a segnali come LD_PRELOAD nel processo init, lo stato contaminato del kernel e correlare gli eventi di caricamento del modulo (ad esempio, finito_modulo) con percorsi insoliti (/opt/*.ko) per rilevare i tentativi di persistenza Presto.

Strumenti, copertura e MITRE ATT&CK

Secondo ESET, è l'unico fornitore tra i primi 20 endpoint per fatturato che integra un Scanner del firmware UEFI nelle loro soluzioni di protezione delle apparecchiature. Sebbene altri produttori offrano tecnologie correlate a UEFI, il loro scopo non sempre coincide con ispezione diretta del firmware. Poiché gli attacchi UEFI, sebbene sporadici, garantiscono controllo totale e persistenza quasi assoluto, investire in questo livello può fare la differenza.

In termini di MITRE ATT&CK, i comportamenti osservati corrispondono a diverse tecniche: Avvio pre-sistema operativo: Bootkit (T1542.003), Moduli condivisi/LD_PRELOAD (T1129), sviluppo di Malware (T1587.001) e l'uso di certificati (T1587.002), Plus Rootkit (T1014), Compromettere le difese (T1562) y Nascondi artefatti (T1564) nel caso di moduli del kernel che si nascondono loro stessi.

• T1542.003: Bootkit sull'ESP per la persistenza pre-OS.
• T1129: Precarica con LD_PRELOAD nel processo init.
• T1014: Moduli del kernel con funzionalità rootkit.
• T1562 / T1564: Disattiva i controlli e nasconditi dal sistema.

Linux non è invulnerabile: il caso Bootkitty e nuovi nomi sul radar

Per anni, la narrativa popolare ha contrapposto la crescente esposizione di Windows alla presunta "impenetrabilità" di macOS o LinuxLa realtà è più sfumata: il loro modello e la loro quota li rendono bersagli diversi, ma non immuni. L'emergere di Bootkitty in Linux dimostra che la conoscenza per creare bootkit esiste anche per questo ecosistema, anche se in questo caso specifico si parla di un PoC accademico con supporto limitato.

Si è parlato anche di una variante del ransomware, HybridPetya, che integrerebbe le funzionalità del bootkit UEFI. Gli esempi caricati su VirusTotal nel 2025 dalla Polonia suggeriscono uno sviluppo recente, anche se dovrebbero essere trattati con cautela. attenzione finché non ci saranno analisi indipendenti e una solida attribuzione.

La cosa importante è interiorizzare che la difesa deve coprire l'intera catena di avvio, minimizzando la fiducia predefinita in firme di terze parti che non vengono utilizzati, monitorare la partizione EFI e consolidare telemetria utile (kernel contaminato, eventi dei moduli, modifiche nei verificatori GRUB o variabili UEFI sensibili) per rilevarli in tempo.

L'attuale quadro del rischio UEFI combina PoC per scopi didattici, bootkit commercializzati come servizio e vulnerabilità nei componenti firmati che, se non revocati in tempo, aprono la porta a esecuzione pre-OS non attendibileMantenere aggiornati firmware ed elenchi di revoca, ridurre il circolo di fiducia e monitorare ESP sono misure che, insieme, mettono i difensori in una posizione molto più forte contro questa famiglia di minacce.

Articolo correlato:

Come proteggere Windows con Credential Guard, BitLocker, AppLocker, Device Guard e WDAC

Isaac

Scrittore appassionato del mondo dei byte e della tecnologia in generale. Adoro condividere le mie conoscenze attraverso la scrittura, ed è quello che farò in questo blog, mostrarti tutte le cose più interessanti su gadget, software, hardware, tendenze tecnologiche e altro ancora. Il mio obiettivo è aiutarti a navigare nel mondo digitale in modo semplice e divertente.