Bootkit: Pre-OS Persistence via Boot Record Modification (T1542.003)

Simulare un bootkit in laboratorio richiede un ambiente isolato — una macchina virtuale con snapshot puliti è il minimo sindacale. L'obiettivo non è creare malware, ma comprendere la meccanica dell'accesso raw al disco e della modifica dei settori di avvio, validando al contempo la capacità di detection del blue team.

Il primo passo è osservare la struttura del MBR su un sistema target. Su Windows, con privilegi elevati, è possibile leggere direttamente il settore zero del disco fisico. Uno script PowerShell può accedere al dispositivo raw \\.\PhysicalDrive0 tramite le API .NET di FileStream, leggendo i primi 512 byte. In ambiente Linux, l'operazione è più immediata:

sudo dd if=/dev/sda of=mbr_backup.bin bs=512 count=1

Questo comando salva il MBR originale — operazione che qualsiasi red teamer dovrebbe eseguire prima di qualunque modifica, sia come baseline sia come rete di sicurezza. Per simulare una sovrascrittura controllata, si può iniettare un pattern riconoscibile nei primi byte (evitando il byte di firma 0x55AA alla posizione 510-511 se si vuole che il disco resti non avviabile come indicatore di compromissione):

sudo dd if=custom_mbr.bin of=/dev/sda bs=512 count=1

Per scenari UEFI, il focus si sposta sulla ESP. Montare la partizione EFI su Linux è banale:

sudo mount /dev/sda1 /mnt/efi

Da qui si possono esplorare i file .efi presenti in /mnt/efi/EFI/Boot/ e sostituire il bootloader legittimo con un binario custom. In un esercizio red team avanzato, strumenti come CHIPSEC (open source) permettono di verificare la configurazione Secure Boot e individuare debolezze nella catena di trust UEFI. Il framework analizza le protezioni firmware, i registri di configurazione SPI e la presenza di write protection sul flash chip.

Per replicare la logica di ROCKBOOT, che modifica il MBR per caricare codice custom prima dell'OS, è utile studiare la struttura del bootloader in assembly x86 a 16 bit. Tool come NASM (open source) consentono di compilare un bootloader minimale:

nasm -f bin bootloader.asm -o bootloader.bin

Il binario risultante può essere scritto nel primo settore della VM di test. Per l'approccio VBR, simile a quanto fa BOOTRASH, occorre identificare la partizione target e sovrascriverne il primo settore — operazione che richiede la comprensione delle strutture NTFS o FAT32 del volume.

Un test complementare consiste nel verificare se il sistema target ha Secure Boot realmente abilitato. Su Windows:

Confirm-SecureBootUEFI

Questo cmdlet PowerShell restituisce True o False. Un red teamer che trova Secure Boot disabilitato ha un vettore d'attacco aperto per l'impianto di bootkit UEFI.

Rilevare un bootkit è una sfida architetturale: l'attacco avviene a un livello che la maggior parte dei sensori EDR non monitora nativamente. La strategia di detection deve quindi combinare indicatori indiretti e controlli di integrità proattivi.

La detection primaria su Windows si basa su Sysmon (open source) e sugli eventi che tracciano l'accesso raw ai dispositivi fisici. L'analisi documentata (AN0428) indica di monitorare l'accesso diretto ai physical drive, la modifica dei boot record e le attività sospette sulla partizione ESP. In Sysmon, l'EventCode 9 (RawAccessRead) cattura le letture dirette su \Device\HarddiskVolume o \\.\PhysicalDrive, mentre l'EventCode 11 (FileCreate) sulla partizione ESP — tipicamente montata su S:\ o accessibile come volume separato — segnala la creazione di file .efi non previsti.

La correlazione è il cuore della detection: un processo privilegiato che esegue accesso raw al disco, seguito da scrittura nella ESP o da caricamento di un driver kernel non firmato, rappresenta una catena comportamentale ad alta confidenza. Il tuning consigliato prevede tre baseline fondamentali:

• KnownGoodMBRHashes: hash dei settori MBR/VBR puliti, acquisiti durante il provisioning della macchina, da confrontare periodicamente
• ESPFileWhitelist: lista dei file EFI legittimi (bootmgfw.efi, grubx64.efi e simili) presenti nella ESP
• TimeWindow: finestra di correlazione tra accesso privilegiato, modifica raw del disco e creazione file EFI — un intervallo di 60 secondi è un punto di partenza ragionevole

Su Linux (AN0429), la detection si appoggia ad auditd con regole mirate. Occorre monitorare le scritture su block device (/dev/sda, /dev/nvme0n1) e l'esecuzione di utility come dd, grub-install ed efibootmgr. Una regola auditd efficace osserva le syscall write e open sui device a blocchi:

-w /usr/sbin/grub-install -p x -k bootloader_mod -w /usr/sbin/efibootmgr -p x -k efi_mod

Queste regole generano eventi SYSCALL nel log di auditd ogni volta che i binari monitorati vengono eseguiti. Per il MBR, è necessaria una regola a livello di device:

-a always,exit -F arch=b64 -S open -S write -F path=/dev/sda -k raw_disk_write

I falsi positivi principali derivano dagli aggiornamenti del sistema operativo e del firmware. Gli aggiornamenti GRUB su Linux e gli update del Boot Manager su Windows toccano legittimamente i file della ESP e i settori di avvio. La chiave è correlare queste attività con il processo padre: un aggiornamento proveniente da apt, dnf o Windows Update è atteso; la stessa operazione eseguita da cmd.exe, powershell.exe o da un binario sconosciuto richiede immediata escalation.

Come controllo preventivo, verificare periodicamente che Secure Boot sia attivo e che il TPM attesti correttamente la catena di avvio. Soluzioni di runtime integrity monitoring completano il quadro rilevando modifiche post-boot ai moduli kernel.

L'analisi forense di un bootkit richiede strumenti e metodologie specifiche, perché gli artefatti risiedono in aree del disco che le acquisizioni forensi standard potrebbero non includere. La prima regola è acquisire un'immagine raw completa del disco, inclusi i settori non allocati e le aree pre-partizione.

L'artefatto primario è il settore MBR stesso (LBA 0, 512 byte). Confrontare l'hash del settore 0 acquisito con l'hash noto del bootloader legittimo del sistema operativo è il test più rapido. Su un'immagine disco, l'estrazione è diretta:

dd if=disk_image.raw of=mbr_extracted.bin bs=512 count=1

L'hash risultante va confrontato con il baseline documentato dall'organizzazione (cfr. tuning KnownGoodMBRHashes). Se l'hash non corrisponde, il settore va disassemblato. Tool come radare2 (open source) permettono di analizzare il codice a 16 bit del MBR:

r2 -b 16 -m 0x7c00 mbr_extracted.bin

L'indirizzo 0x7c00 è la locazione standard in cui il BIOS carica il MBR. L'analisi del disassemblato può rivelare jump anomali, routine di decifratura o referenze a settori nascosti — tutti indicatori di bootkit come ROCKBOOT o delle varianti MBR di FinFisher.

Per i bootkit VBR, come BOOTRASH, l'analisi si estende ai primi settori di ciascuna partizione. Su un volume NTFS, il VBR contiene il codice IPL (Initial Program Loader) che carica NTLDR o bootmgr. Alterazioni a questa area sono rilevabili confrontando la struttura del VBR con un template NTFS pulito.

In ambienti UEFI, la EFI System Partition è il target. Montare l'immagine della ESP e calcolare gli hash di ogni file .efi presente consente di identificare binari non firmati o modificati. Lo strumento pesign (open source, ecosistema Linux) verifica le firme Authenticode dei binari PE/EFI:

pesign -S -i bootmgfw.efi

Un binario EFI privo di firma valida o con una firma non riconosciuta dalla catena Secure Boot è un indicatore forte di compromissione.

La timeline deve correlare gli artefatti disco con i log di sistema. WhisperGate, ad esempio, sovrascrive il MBR con un bootloader distruttivo che visualizza una falsa nota di riscatto: il timestamp della modifica del settore 0, incrociato con gli eventi di esecuzione del processo iniziale nei log Sysmon o nei journal di Windows, permette di ricostruire la sequenza dell'attacco. Analogamente, per i casi attribuiti a Lazarus Group, dove il malware WhiskeyAlfa-Three modifica il settore 0 per garantire persistenza, la presenza di codice anomalo nel MBR combinata con artefatti di lateral movement nei log Windows ricostruisce la catena di compromissione.

Un elemento spesso trascurato è il TPM Event Log, accessibile su Windows tramite il percorso del registro HKLM\SYSTEM\CurrentControlSet\Services\TPM. Quando il TPM attesta la sequenza di boot, registra gli hash dei componenti caricati — un hash del bootloader che cambia tra due avvii consecutivi è evidenza diretta di modifica.

La capacità di impiantare un bootkit definisce un profilo di threat actor con accesso a competenze firmware-level e ambizioni di persistenza a lungo termine. I tre gruppi documentati rappresentano tre filosofie operative distinte.

APT41 — attore cinese noto per la doppia matrice spionaggio/cybercrime — ha impiegato bootkit MBR su sistemi Windows come layer aggiuntivo di occultamento. La scelta del bootkit si inserisce nel loro approccio stratificato alla persistenza: non un singolo meccanismo, ma layer multipli e ridondanti. Il fatto che APT41 mantenga capacità bootkit indica investimento in R&D firmware che pochi gruppi possono permettersi.

Lazarus Group — attore nordcoreano — ha utilizzato il malware WhiskeyAlfa-Three per modificare il settore 0 del MBR, garantendo persistenza anche attraverso spegnimenti del sistema. In questo caso il bootkit serve uno scopo operativo preciso: mantenere l'accesso in ambienti dove la vittima potrebbe spegnere fisicamente la macchina come contromisura d'emergenza. Il pattern è coerente con le operazioni distruttive e finanziarie attribuite al gruppo.

APT28 — attore russo — ha deployato un bootkit congiuntamente a Downdelph per consolidare la persistenza. Un dato significativo è la condivisione di codice tra questo bootkit e alcune varianti di BlackEnergy, suggerendo un ecosistema di sviluppo condiviso o il riuso di componenti tra programmi offensivi distinti nell'orbita degli stessi sponsor statali.

Sul fronte del software, la distinzione tra tool di persistenza e tool distruttivi è cruciale. ROCKBOOT (MBR) e BOOTRASH (VBR) sono strumenti di persistenza pura — il bootkit serve a mantenere l'accesso. Carberp e FinFisher incorporano capacità bootkit come modulo accessorio di un framework più ampio. TrickBot, con la sua capacità di impiantare codice nel firmware, ha rappresentato un'evoluzione preoccupante nel panorama crimeware, portando capacità precedentemente riservate a gruppi statali nel dominio del cybercrime-as-a-service. WhisperGate costituisce un caso anomalo: qui il bootkit non serve persistenza ma distruzione, sovrascrivendo il MBR con un bootloader che simula ransomware mentre esegue wiping irreversibile.

Il pattern geografico rivela che la capacità bootkit è concentrata tra attori statali di Cina, Russia e Corea del Nord — nazioni con programmi cyber offensivi maturi e investimenti in ricerca firmware. L'overlap di codice tra il bootkit di APT28 e BlackEnergy suggerisce catene di approvvigionamento interne agli ecosistemi offensivi nazionali. Il trend emergente è la migrazione da bootkit MBR/VBR legacy verso varianti UEFI/ESP, coerente con la progressiva obsolescenza dei sistemi BIOS.

Framework MITRE ATT&CK v16 — T1542.003 (Bootkit), tattiche TA0003 e TA0005. Gruppi: G0096, G0032, G0007. Software: S0484, S0689, S0266, S0112, S0114, S0182. Mitigazioni: M1046, M1026. Detection: DET0150 (AN0428, AN0429). Integrato con conoscenza professionale per tool e procedure operative.