Rootkit Firmware: System Firmware (T1542.001)

In un contesto red team la simulazione di T1542.001 richiede un laboratorio isolato, hardware dedicato e piena consapevolezza del rischio di bricking. Non si tratta di una tecnica da eseguire su asset produttivi: un flash fallito può rendere la macchina irrecuperabile senza intervento hardware sul chip SPI.

La fase di ricognizione parte dall'enumerazione del firmware presente. Su Windows il comando wmic bios get manufacturer,smbiosbiosversion,releasedate restituisce vendor, versione e data del BIOS installato, mentre Get-CimInstance -ClassName Win32_BIOS in PowerShell offre lo stesso dato in forma strutturata. Su Linux si utilizza dmidecode -t bios (open source, incluso in quasi tutte le distribuzioni) per ottenere le stesse informazioni, integrato da fwupdmgr get-devices del progetto fwupd (open source) per elencare i dispositivi con firmware aggiornabile.

L'analisi del firmware estratto avviene con CHIPSEC (open source, sviluppato da Intel), il framework di riferimento per audit di sicurezza a basso livello. Il comando chipsec_main -m common.bios_wp verifica se la protezione di scrittura del BIOS è attiva; chipsec_util spi dump firmware.bin estrae il contenuto della flash SPI per analisi offline. L'immagine estratta si analizza con UEFITool (open source) per esplorare la struttura del volume firmware e con binwalk (open source) per identificare componenti embedded.

Per emulare un impianto in ambiente virtualizzato senza rischi, il progetto OVMF (open source, parte di TianoCore/EDK II) fornisce un firmware UEFI compilabile che può essere modificato con moduli DXE personalizzati e caricato in QEMU (open source). Questo permette di sviluppare e testare payload che scrivono su NVRAM o installano hook al boot senza toccare hardware fisico.

Una catena d'attacco plausibile parte dall'ottenimento di privilegi SYSTEM/root sull'host, prosegue con la verifica delle protezioni firmware attive (BIOS Write Protect, BIOS Lock Enable, SMM_BWP), sfrutta eventuali vulnerabilità del vendor per bypassare il locking e infine invoca l'utility di flash legittima del produttore con un'immagine modificata. La famiglia LoJax dimostra proprio questo pattern: sfruttando la mancanza di Secure Boot su firmware datati, l'agente veniva scritto direttamente nella regione SPI e ricaricava un componente user-mode a ogni boot.

In fase di reporting il red team deve documentare quali controlli sono stati bypassati (Secure Boot disabilitato, BIOS password assente, firmware non aggiornato con CVE note) come input diretto per le raccomandazioni difensive.

La detection di T1542.001 è tra le più complesse per un SOC perché il codice malevolo, una volta insediato, opera prima del caricamento dei sensori EDR. La strategia efficace si sposta quindi sulla fase di scrittura del firmware e sulle anomalie di boot correlate.

La strategia DET0099 proposta da MITRE indica come punto di partenza la sorveglianza di operazioni di scrittura verso regioni firmware BIOS/UEFI e verso la partizione EFI System. Su Windows le fonti principali sono WinEventLog:Security e WinEventLog:Sysmon: l'esecuzione di fwupdate.exe o di utility vendor di flashing (Dell Command Update, HP BIOS Configuration Utility, Lenovo ThinkVantage) da parte di account non appartenenti al team IT o fuori dalle finestre di manutenzione approvate è un forte segnale di allarme. Con Sysmon (gratuito, Microsoft), l'EventID 1 per la creazione di processi e l'EventID 11 per la scrittura di file sulla partizione ESP (*\Device\HarddiskVolume1\EFI*) costituiscono le regole base.

Per i dispositivi di rete (analytic AN0276), il monitoraggio si concentra su upload di immagini firmware via TFTP, FTP o SCP verso router e switch, e sulla modifica delle variabili di boot che puntano a immagini non standard. I log networkdevice:config e networkdevice:runtime vanno correlati con reboot inattesi che seguono modifiche di configurazione.

Il tuning delle regole richiede baseline solide. È indispensabile mantenere una whitelist di AllowedFirmwareUpdateTools — le utility vendor autorizzate — una definizione precisa delle MaintenanceWindows in cui gli aggiornamenti firmware sono attesi, e un repository di KnownGoodFirmwareHashes per confronto d'integrità. Senza queste baseline il tasso di falsi positivi durante le campagne di patching aziendale diventa insostenibile.

Sul fronte D3FEND, le contromisure rilevanti sono System Firmware Verification e TPM Boot Integrity: entrambe si basano sull'attestazione hardware del firmware caricato tramite Trusted Platform Module, con misurazioni memorizzate nei PCR che possono essere estratte via tpm2_pcrread (open source, tpm2-tools) e confrontate con valori attesi. Soluzioni enterprise come Microsoft Defender for Endpoint (a pagamento) integrano telemetria di boot integrity tramite il servizio Windows Defender System Guard Runtime Attestation.

I principali falsi positivi derivano da aggiornamenti firmware legittimi automatizzati (Dell Command Update, Lenovo System Update, HP Image Assistant), da attività di provisioning OEM su nuovi endpoint e da tool di IT asset management che interrogano le informazioni BIOS via WMI. La correlazione temporale con i ticket di change management è il filtro più efficace per ridurre il rumore.

L'analisi forense di un compromesso a livello T1542.001 ribalta l'approccio tradizionale: il disco rigido può essere pulito e il sistema operativo appena reinstallato, ma l'impianto persiste nella flash SPI. La raccolta delle evidenze deve quindi includere obbligatoriamente il dump del firmware oltre alle immagini disco e memoria.

Su un sistema Windows attivo, la prima acquisizione riguarda l'immagine del firmware corrente. CHIPSEC (open source, Intel) con chipsec_util spi dump firmware.bin estrae l'intero contenuto della SPI flash. In parallelo, chipsec_main eseguito con i moduli common.bios_wp, common.bios_smi e common.secureboot.variables documenta lo stato delle protezioni al momento dell'analisi. L'immagine estratta va quindi confrontata con il golden image fornito dal vendor tramite hash SHA-256 e, se disponibile, con database pubblici come UEFI Firmware Repository o LVFS (Linux Vendor Firmware Service, gratuito).

Per l'analisi strutturale del firmware, UEFITool (open source) permette di navigare i volumi firmware e identificare moduli DXE non firmati o inseriti fuori dallo schema atteso. Anomalie tipiche degli impianti noti includono moduli con nomi che imitano componenti legittimi ma con timestamp o firme incongruenti, e sezioni raw contenenti stringhe ASCII sospette (URL di C2, path di file droppati). Per LoJax, l'analisi rivelò un modulo DXE chiamato SecDxe con capacità di scrittura NTFS che rilasciava componenti nel filesystem a ogni boot.

Sul filesystem, gli artefatti correlati si trovano nella partizione EFI System Partition (montabile con mountvol su Windows o mount /dev/sda1 /mnt/esp su Linux). File .efi non firmati, entry non standard in *\EFI\Boot* o *\EFI\Microsoft\Boot*, e modifiche recenti al BCD (Boot Configuration Data) sono indicatori diretti. Il comando bcdedit /enum all documenta la configurazione di boot corrente.

La timeline forense integra le variabili NVRAM. Su Linux efivar -l (pacchetto efivar, open source) elenca tutte le variabili UEFI presenti; su Windows Get-SecureBootUEFI in PowerShell recupera lo stato Secure Boot e le chiavi PK/KEK/db/dbx. Variabili con GUID non riconducibili al vendor o con contenuto binario anomalo meritano estrazione e analisi.

Per il caso Trojan.Mebromi, l'analisi documentata mostrò modifiche al MBR e al modulo BIOS che ripristinavano il payload anche dopo la disinfezione del disco. Per Hacking Team UEFI Rootkit, gli artefatti includevano moduli DXE che scrivevano eseguibili nella cartella Startup dell'utente a ogni boot. In entrambi i casi la memoria volatile acquisita con WinPmem o LiME (entrambi open source) mostrava processi utente lanciati dal firmware ma senza parent process tracciabile nel normale albero.

I dati MITRE per T1542.001 non elencano gruppi APT esplicitamente mappati, ma le tre famiglie malware documentate raccontano un profilo di minaccia chiaro: strumenti di livello statale o para-statale, sviluppati con investimento significativo e utilizzati in operazioni ad alto valore dove la persistenza sopravvive a qualunque rimediazione tradizionale.

LoJax (S0397) rappresenta il primo rootkit UEFI documentato pubblicamente come impiegato in operazioni reali. Il payload derivava da un abuso del software commerciale legittimo LoJack for Laptops (antitheft di Absolute Software), i cui componenti erano stati modificati per comunicare con infrastruttura C2 controllata dagli attaccanti anziché con i server legittimi del vendor. L'impianto veniva scritto nella flash SPI sfruttando la mancanza di protezioni di scrittura su firmware datati, e a ogni boot ricaricava un agente user-mode nel sistema operativo. Il target documentato era il settore governativo dell'Europa orientale.

Hacking Team UEFI Rootkit (S0047) ha una genesi peculiare: sviluppato dall'azienda italiana Hacking Team come componente della suite di sorveglianza commerciale Remote Control System, la sua esistenza divenne pubblica con il leak del 2015 che espose il codice sorgente e la documentazione operativa. Il rootkit era progettato per garantire che il software di sorveglianza sopravvivesse a reinstallazioni del sistema operativo eseguite dall'utente, un requisito tipico degli scenari di lawful interception in cui il target è consapevole di essere sotto attenzione. La disponibilità pubblica del codice ne ha ampliato la superficie di riuso da parte di attori terzi.

Trojan.Mebromi (S0001) appartiene invece a un lignaggio più datato, orientato al BIOS legacy piuttosto che a UEFI. Distribuito principalmente in campagne cinesi nei primi anni 2010, dimostrava una tecnica di infezione del BIOS Award che ripristinava un dropper nel MBR anche dopo pulizia del disco. Rappresenta storicamente la prova di concetto che ha aperto la strada alle generazioni successive di impianti firmware.

I pattern comuni emergono con chiarezza. Il primo è la scelta di target ad alto valore: governi, difesa, dissidenti, giornalisti — mai operazioni di massa, per non bruciare la capacità. Il secondo è lo sfruttamento di firmware non aggiornati o mal configurati (Secure Boot disabilitato, BIOS Write Protect non impostato): la barriera d'ingresso è meno tecnica di quanto sembri quando la superficie difensiva è debole. Il terzo trend è la convergenza tra impianti firmware sviluppati da fornitori commerciali di offensive security e loro migrazione, per leak o riuso, verso ecosistemi APT.

La prospettiva evolutiva vede una crescita di interesse verso attacchi ai baseboard management controller (BMC/iDRAC/iLO), estensione naturale del concetto di persistenza sub-OS su infrastruttura server.

MITRE ATT&CK: tecnica T1542.001, tattiche TA0003 e TA0005, software S0001 (Trojan.Mebromi), S0047 (Hacking Team UEFI Rootkit), S0397 (LoJax), mitigazioni M1026, M1046, M1051, detection strategy DET0099 con analytic AN0275 e AN0276. MITRE D3FEND per contromisure System Firmware Verification e TPM Boot Integrity. Tool di detection e analisi citati: CHIPSEC, UEFITool, fwupd, tpm2-tools, Sysmon, WinPmem, LiME. Integrata conoscenza professionale su procedure operative red team, artefatti forensi UEFI ed EFI System Partition, e contesto storico delle famiglie malware documentate.